code-ai-installer 1.5.1 → 1.5.3

package/.agents/workflows/pipeline-rules.md

@@ -1,137 +1,163 @@
----
-description: Абсолютные правила пайплайна разработки. ЗАПРЕЩЕНО НАРУШАТЬ.
----
-
-# 🔴 АБСОЛЮТНОЕ ПРАВИЛО: Пайплайн запрещено пропускать
-
-**Это правило не имеет исключений. Нарушение = блокер.**
-
-## Пайплайн (8 гейтов)
-
-TEST → PM → UX → ARCH → DEV → REV → OPS → TEST
-
-## Обязательные действия на КАЖДОМ гейте
-
-1. `view_file` на `agents/<role>.md` — прочитать протокол агента
-2. Следовать **его** инструкциям, использовать **его** skills
-3. Сформировать deliverable + Handoff Envelope
-4. Представить результат пользователю через `notify_user`
-5. **Ждать явный "Approved" от пользователя** перед переходом к следующему гейту
-
----
-
-## 🛑 СТОП-ПРАВИЛА (перед каждым действием с кодом)
-
-### Правило 1: Протокол агента — пошагово, не «схлопывая»
-Каждый параграф (§) в файле агента = **отдельный шаг**.
-- Агент ОБЯЗАН пройти ВСЕ параграфы в порядке, указанном в файле
-- Запрещено «схлопывать» несколько §§ в один ответ
-- Если агент пропускает §, он ОБЯЗАН указать причину: «§X пропущен: [причина]»
-
-### Правило 2: Код применяется ТОЛЬКО после полного прохода протокола
-- ❌ Нельзя: сначала написать код → потом написать отчёт
-- ✅ Нужно: пройти все §§ протокола → представить план → Approved → применить код
-
-### Правило 3: Полный формат ответа — без сокращений
-- Использовать **«Формат ответа агента (строго)»** из файла агента
-- Каждая секция формата ОБЯЗАТЕЛЬНА — пропуск = нарушение
-- Если секция не применима, явно написать: «N/A — [причина]»
-
-### Правило 4: Fix Cycle — полный проход через агентов
-При FAIL на любом гейте:
-1. Текущий агент (напр. Tester) выдаёт FAIL Report + HANDOFF Envelope → DEV
-2. DEV читает `agents/senior_full_stack.md` и проходит ПОЛНЫЙ протокол (§0–§7)
-3. DEV HANDOFF → REV → OPS → TEST (каждый гейт с view_file + протокол + Approved)
-4. Никаких «быстрых фиксов» без прохода через агентов
-
-### Правило 5: Самопроверка перед notify_user
-Перед каждым `notify_user` агент ОБЯЗАН внутренне проверить:
-- [ ] Прочитал ли я файл агента (`view_file` на `agents/<role>.md`)?
-- [ ] Прошёл ли я ВСЕ параграфы протокола?
-- [ ] Использую ли я ПОЛНЫЙ формат ответа?
-- [ ] Есть ли HANDOFF Envelope со ВСЕМИ обязательными полями?
-- [ ] НЕ применял ли я код до получения Approved?
-
----
-
-## Запрещено
-
-- ❌ «Fast-track» гейтов (пропуск нескольких гейтов за раз)
-- ❌ Интерпретировать «Подтверждаю» как разрешение пропустить гейты
-- ❌ Начинать пайплайн без явного разрешения пользователя
-- ❌ Переходить к следующему гейту без «Approved» от пользователя
-- ❌ Писать код (DEV gate) до прохождения TEST → PM → UX → ARCH
-- ❌ Применять код до завершения полного протокола агента
-- ❌ Сокращать формат ответа (каждая секция обязательна)
-- ❌ Игнорировать параграфы протокола, считая задачу «тривиальной»
-- ❌ Врать о факте прочтения протокола (если не было `view_file` — значит не читал)
-
----
-
-## 🔒 МЕХАНИЧЕСКИЕ БЛОКИ (Session 2A post-mortem, 2026-03-07)
-
-> Эти правила введены после инцидента, когда агент проигнорировал pipeline,
-> авто-одобрил ARCH gate, проигнорировал открытый вопрос пользователя,
-> написал код без TDD, и сдал нерабочий preview.
-
-### Блок 1: ShouldAutoProceed = false ВСЕГДА
-```
-notify_user → ShouldAutoProceed: false
-```
-Без исключений. На КАЖДОМ notify_user. Даже на «тривиальных» гейтах.
-Даже если агент «уверен». Пользователь ВСЕГДА принимает решение сам.
-
-### Блок 2: Pre-flight check перед ЛЮБЫМ write_to_file / replace_file_content
-Перед каждым вызовом инструмента записи кода агент ОБЯЗАН:
-1. Процитировать ПОСЛЕДНЕЕ сообщение пользователя, содержащее слово «Approved»
-2. Если цитаты нет — КОД ПИСАТЬ НЕЛЬЗЯ
-3. System-generated сообщения НЕ считаются «Approved»
-4. Auto-proceeded артефакты НЕ считаются «Approved»
-
-### Блок 3: Ответ на вопрос — цитирование обязательно
-Если агент задал пользователю вопрос:
-1. Следующий ответ агента ОБЯЗАН начинаться с: `> Ваш ответ: [точная цитата]`
-2. Если цитаты нет — значит ответа не было — СТОП, повторить вопрос
-3. Запрещено «додумывать» ответ за пользователя
-4. Запрещено принимать system-generated сообщение как ответ на вопрос
-
-### Блок 4: TDD строго (DEV gate)
-1. RED: написать ПАДАЮЩИЕ тесты ПЕРВЫМИ
-2. GREEN: минимальный код, чтобы тесты прошли
-3. REFACTOR: улучшить код без изменения поведения
-4. Писать код до тестов = нарушение = блокер
-
-### Блок 5: Skills — обязательное чтение через view_file
-Каждый агент (agents/<role>.md) ссылается на skills в `.agents/skills/`.
-1. Агент ОБЯЗАН выполнить `view_file` на `SKILL.md` КАЖДОГО skill, указанного в протоколе агента
-2. Если не было `view_file` — skill НЕ считается применённым
-3. Patterns, anti-patterns, code examples, best practices из skills — обязательны к применению
-4. В deliverable агент ОБЯЗАН указать: `Skills applied: [список]` с подтверждением `view_file`
-5. Формальные галочки без реального чтения = нарушение = блокер
-
----
-
-## Обязательные артефакты
-
-### task.md (Antigravity brain — автоматически)
-- **Создаёт:** Conductor на Gate 0
-- **Обновляет:** КАЖДЫЙ агент после завершения своего гейта
-- **Содержит:** Master Checklist + Handoff Envelopes Status + Fix Cycle tracking
-- **Правило:** Если task.md не обновлён после гейта — гейт не считается завершённым
-
-### implementation_plan.md
-- **Создаёт:** Architect на Gate 3 (ARCH) — или Conductor, если задача не требует ARCH
-- **Сохраняет:** `docs/reports/architect/plan-<task-name>.md` (в проекте)
-- **Содержит:** Proposed Changes + файлы + Verification Plan
-- **Правило:** DEV обязан прочитать plan перед началом реализации. Reviewer сверяется при code review.
-
-### walkthrough.md (Antigravity brain — автоматически)
-- **Создаёт:** Tester на Gate 7 (TEST) — или Release Gate
-- **Содержит:** что сделано, что проверено, результаты валидации
-- **Правило:** обновлять при каждом Fix Cycle и перед Release Gate
-
-### docs/architecture.md + docs/ADR-log.md (в проекте)
-- **Обновляет:** Architect при любом архитектурном решении
-- **Сверяются:** Reviewer и Architect на каждом гейте
-- **Правило:** Новые ADR добавляются в ADR-log.md. Architecture.md обновляется при изменении стека, паттернов или ограничений
-
+---
+description: Абсолютные правила пайплайна разработки. ЗАПРЕЩЕНО НАРУШАТЬ.
+---
+
+# 🔴 АБСОЛЮТНОЕ ПРАВИЛО: Пайплайн запрещено пропускать
+
+**Это правило не имеет исключений. Нарушение = блокер.**
+
+## Пайплайн — 3 режима
+
+### 🔵 Full Pipeline (8 гейтов) — `/start-task`
+CONDUCTOR → PM → UX → ARCH → DEV → REV → OPS → TEST → RG
+
+### 🟢 Bugfix Pipeline (4 гейта) — `/bugfix`
+CONDUCTOR → DEV → REV → TEST
+
+### 🟡 Hotfix Pipeline (2 гейта) — `/hotfix`
+CONDUCTOR → DEV+TEST
+
+### Decision Tree (выбор режима)
+```
+Задача от пользователя
+  │
+  ├─ Новая фича / рефакторинг / новый API / новый экран?
+  │    └─ 🔵 Full Pipeline
+  │
+  ├─ Баг в существующем функционале?
+  │    ├─ Затрагивает > 2 файлов или меняет контракт API?
+  │    │    └─ 🟢 Bugfix (4 гейта)
+  │    ├─ Затрагивает 1–2 файла, blast radius ≈ 0?
+  │    │    └─ 🟡 Hotfix (2 гейта)
+  │    └─ Не уверен → спросить пользователя
+  │
+  └─ Пользователь явно указал режим (/bugfix, /hotfix)?
+       └─ Использовать указанный
+```
+
+> Conductor **не получает новых skills** — использует существующие `$board`, `$handoff`, `$gates`.
+
+## Обязательные действия на КАЖДОМ гейте (все режимы)
+
+1. `view_file` на `agents/<role>.md` — прочитать протокол агента
+2. Следовать **его** инструкциям, использовать **его** skills
+3. Сформировать deliverable + Handoff Envelope
+4. Представить результат пользователю через `notify_user`
+5. **Ждать явный "Approved" от пользователя** перед переходом к следующему гейту
+
+---
+
+## 🛑 СТОП-ПРАВИЛА (перед каждым действием с кодом)
+
+### Правило 1: Протокол агента — пошагово, не «схлопывая»
+Каждый параграф (§) в файле агента = **отдельный шаг**.
+- Агент ОБЯЗАН пройти ВСЕ параграфы в порядке, указанном в файле
+- Запрещено «схлопывать» несколько §§ в один ответ
+- Если агент пропускает §, он ОБЯЗАН указать причину: «§X пропущен: [причина]»
+
+### Правило 2: Код применяется ТОЛЬКО после полного прохода протокола
+- ❌ Нельзя: сначала написать код → потом написать отчёт
+- ✅ Нужно: пройти все §§ протокола → представить план → Approved → применить код
+
+### Правило 3: Полный формат ответа — без сокращений
+- Использовать **«Формат ответа агента (строго)»** из файла агента
+- Каждая секция формата ОБЯЗАТЕЛЬНА — пропуск = нарушение
+- Если секция не применима, явно написать: «N/A — [причина]»
+
+### Правило 4: Fix Cycle — полный проход через агентов
+При FAIL на любом гейте:
+1. Текущий агент (напр. Tester) выдаёт FAIL Report + HANDOFF Envelope → DEV
+2. DEV читает `agents/senior_full_stack.md` и проходит ПОЛНЫЙ протокол (§0–§7)
+3. DEV HANDOFF → REV → OPS → TEST (каждый гейт с view_file + протокол + Approved)
+4. Никаких «быстрых фиксов» без прохода через агентов
+
+### Правило 5: Самопроверка перед notify_user
+Перед каждым `notify_user` агент ОБЯЗАН внутренне проверить:
+- [ ] Прочитал ли я файл агента (`view_file` на `agents/<role>.md`)?
+- [ ] Прошёл ли я ВСЕ параграфы протокола?
+- [ ] Использую ли я ПОЛНЫЙ формат ответа?
+- [ ] Есть ли HANDOFF Envelope со ВСЕМИ обязательными полями?
+- [ ] НЕ применял ли я код до получения Approved?
+
+---
+
+## Запрещено
+
+- ❌ «Fast-track» гейтов (пропуск нескольких гейтов за раз)
+- ❌ Интерпретировать «Подтверждаю» как разрешение пропустить гейты
+- ❌ Начинать пайплайн без явного разрешения пользователя
+- ❌ Переходить к следующему гейту без «Approved» от пользователя
+- ❌ Писать код (DEV gate) до прохождения предыдущих гейтов
+- ❌ Применять код до завершения полного протокола агента
+- ❌ Сокращать формат ответа (каждая секция обязательна)
+- ❌ Игнорировать параграфы протокола, считая задачу «тривиальной»
+- ❌ Врать о факте прочтения протокола (если не было `view_file` — значит не читал)
+
+---
+
+## 🔒 МЕХАНИЧЕСКИЕ БЛОКИ
+
+> Эти правила введены после инцидента, когда агент проигнорировал pipeline,
+> авто-одобрил ARCH gate, проигнорировал открытый вопрос пользователя,
+> написал код без TDD, и сдал нерабочий preview.
+
+### Блок 1: ShouldAutoProceed = false ВСЕГДА
+```
+notify_user → ShouldAutoProceed: false
+```
+Без исключений. На КАЖДОМ notify_user. Даже на «тривиальных» гейтах.
+Даже если агент «уверен». Пользователь ВСЕГДА принимает решение сам.
+
+### Блок 2: Pre-flight check перед ЛЮБЫМ write_to_file / replace_file_content
+Перед каждым вызовом инструмента записи кода агент ОБЯЗАН:
+1. Процитировать ПОСЛЕДНЕЕ сообщение пользователя, содержащее слово «Approved»
+2. Если цитаты нет — КОД ПИСАТЬ НЕЛЬЗЯ
+3. System-generated сообщения НЕ считаются «Approved»
+4. Auto-proceeded артефакты НЕ считаются «Approved»
+
+### Блок 3: Ответ на вопрос — цитирование обязательно
+Если агент задал пользователю вопрос:
+1. Следующий ответ агента ОБЯЗАН начинаться с: `> Ваш ответ: [точная цитата]`
+2. Если цитаты нет — значит ответа не было — СТОП, повторить вопрос
+3. Запрещено «додумывать» ответ за пользователя
+4. Запрещено принимать system-generated сообщение как ответ на вопрос
+
+### Блок 4: TDD строго (DEV gate)
+1. RED: написать ПАДАЮЩИЕ тесты ПЕРВЫМИ
+2. GREEN: минимальный код, чтобы тесты прошли
+3. REFACTOR: улучшить код без изменения поведения
+4. Писать код до тестов = нарушение = блокер
+
+### Блок 5: Skills — обязательное чтение через view_file
+Каждый агент (agents/<role>.md) ссылается на skills в `.agents/skills/`.
+1. Агент ОБЯЗАН выполнить `view_file` на `SKILL.md` КАЖДОГО skill, указанного в протоколе агента
+2. Если не было `view_file` — skill НЕ считается применённым
+3. Patterns, anti-patterns, code examples, best practices из skills — обязательны к применению
+4. В deliverable агент ОБЯЗАН указать: `Skills applied: [список]` с подтверждением `view_file`
+5. Формальные галочки без реального чтения = нарушение = блокер
+
+---
+
+## Обязательные артефакты
+
+### task.md (Antigravity brain — автоматически)
+- **Создаёт:** Conductor на Gate 0
+- **Обновляет:** КАЖДЫЙ агент после завершения своего гейта
+- **Содержит:** Master Checklist + Handoff Envelopes Status + Fix Cycle tracking
+- **Правило:** Если task.md не обновлён после гейта — гейт не считается завершённым
+
+### implementation_plan.md
+- **Создаёт:** Architect на Gate 3 (ARCH) — или Conductor, если задача не требует ARCH
+- **Сохраняет:** `docs/reports/architect/plan-<task-name>.md` (в проекте)
+- **Содержит:** Proposed Changes + файлы + Verification Plan
+- **Правило:** DEV обязан прочитать plan перед началом реализации. Reviewer сверяется при code review.
+
+### walkthrough.md (Antigravity brain — автоматически)
+- **Создаёт:** Tester на Gate 7 (TEST) — или Release Gate
+- **Содержит:** что сделано, что проверено, результаты валидации
+- **Правило:** обновлять при каждом Fix Cycle и перед Release Gate
+
+### docs/architecture.md + docs/ADR-log.md (в проекте)
+- **Обновляет:** Architect при любом архитектурном решении
+- **Сверяются:** Reviewer и Architect на каждом гейте
+- **Правило:** Новые ADR добавляются в ADR-log.md. Architecture.md обновляется при изменении стека, паттернов или ограничений

package/.agents/workflows/start-task.md

@@ -1,121 +1,130 @@
----
-description: Шаблон запуска задачи через 8-агентный пайплайн. Используй в начале КАЖДОЙ сессии.
----
-
-# /start-task — Запуск задачи через пайплайн
-
-## Шаг 1: Загрузить правила пайплайна
-
-Выполни `/pipeline-rules` — прочитай и подтверди ВСЕ правила ПЕРЕД началом работы.
-
-## Шаг 2: Инициализировать агентов
-Выполни `view_file` на `AGENTS.md` — подтверди список агентов и skills.
-
-## Шаг 3: Запустить Дирижёра
-Выполни `view_file` на `agents/conductor.md` — прочитай протокол и создай Master Checklist в `task.md`.
-
-## Шаг 4: Пройти каждый гейт СТРОГО по протоколу
-
-На КАЖДОМ гейте обязательно:
-1. `view_file` на `agents/<role>.md` — прочитать протокол агента
-2. Пройти КАЖДУЮ секцию протокола по порядку (не «схлопывать»)
-3. Использовать **полный** «Формат ответа агента (строго)» из файла агента
-4. Если секция не применима — явно написать: «N/A — [причина]»
-5. Сформировать deliverable + Handoff Envelope со ВСЕМИ обязательными полями
-6. Представить результат через `notify_user`
-7. **Ждать явный "Approved"** перед переходом к следующему гейту
-
-## Шаг 5: Код — ТОЛЬКО после DEV gate + Approved
-
-- Сначала DEV-агент проходит ВСЕ секции протокола (§0–§7)
-- Потом предлагает план изменений
-- Пользователь одобряет
-- ТОЛЬКО ПОТОМ агент применяет код
-
-## Шаг 6: Fix Cycle (при FAIL)
-
-Если тестер или ревьюер нашёл баг:
-1. Текущий агент выдаёт FAIL Report + HANDOFF Envelope → DEV
-2. Пользователь одобряет FAIL HANDOFF
-3. DEV читает `agents/senior_full_stack.md` и проходит ПОЛНЫЙ протокол
-4. DEV HANDOFF → REV → OPS → TEST (каждый гейт с полным протоколом)
-5. Никаких «быстрых фиксов» без прохода через агентов
-
----
-
-## Шаблон первого промпта (копируй и заполни)
-
-```
-@AGENTS.md /pipeline-rules
-
-Задача: [что сделать, 1-2 предложения].
-Файлы: [конкретные файлы, если известны].
-
-Правила:
-1. Начинай с Дирижёра (agents/conductor.md)
-2. Каждый гейт: view_file → ВСЕ секции протокола → полный формат → Approved
-3. Код не применять до DEV gate + мой Approved
-4. Fix Cycle = полный проход через агентов
-```
-
----
-
-## Рекомендации по сессиям
-
-- **Одна сессия = 3-4 гейта максимум** (контекст не теряется)
-- **Approved даётся на КАЖДОМ гейте**, не на сессию
-- **Сессия 1:** Conductor → Approved → PM → Approved → UX → Approved
-- **Сессия 2:** ARCH → Approved → DEV → Approved → REV → Approved
-- **Сессия 3:** OPS → Approved → TEST → Approved → RG → Approved
-- Каждая новая сессия — начинай с `/start-task`
-
-## Обязательные вопросы от агентов
-
-Каждый агент, у которого в протоколе есть Clarification/Questions секция, ОБЯЗАН:
-1. Задать вопросы пользователю ПЕРЕД выполнением работы
-2. Минимум вопросов (из протокола агента): PM — 5+, ARCH — 5-10, DEV — по необходимости, Tester — 5+
-3. Если задача кажется «очевидной» — всё равно задать минимум 2-3 уточняющих вопроса
-4. Ждать ответы пользователя ПЕРЕД продолжением
-5. Единственное исключение: пользователь явно написал «вопросов не задавай»
-
-## При «срезании углов» — одна фраза
-
-Если модель сокращает, скажи:
-> «Стоп. Секция [X] протокола agents/<role>.md. Перечитай и выполни.»
-
----
-
-## Протокол обратной связи (обязательно)
-
-Модель ОБЯЗАНА предоставлять обратную связь пользователю на каждом этапе:
-
-### 1. Предупреждение при соблазне срезать
-Если задача выглядит «тривиальной», модель ОБЯЗАНА написать:
-```
-⚠️ Задача выглядит тривиальной. Мой инстинкт — сделать быстро.
-Но по протоколу прохожу полный цикл. Секции: [список].
-```
-
-### 2. Оценка промпта пользователя
-В начале каждой задачи модель оценивает промпт:
-```
-📊 Оценка промпта:
-- Чёткость: [высокая/средняя/низкая]
-- Что хорошо: [что помогло]
-- Чего не хватает: [что добавить для эффективности]
-```
-
-### 3. Подсказки в Handoff Envelope
-В каждом Handoff добавлять секцию:
-```
-💡 Feedback: [совет для пользователя, если есть]
-```
-
-### 4. Ретроспектива в конце сессии
-Перед завершением работы:
-```
-🔄 Ретроспектива:
-- Гейтов пройдено: X
-- Нарушений протокола: X
-- Что улучшить в следующей сессии: [рекомендация]
+---
+description: Шаблон запуска задачи через 8-агентный пайплайн. Используй в начале КАЖДОЙ сессии.
+---
+
+# /start-task — Запуск задачи через пайплайн
+
+## Шаг 0: Выбрать режим пайплайна
+
+Определи тип задачи и выбери workflow:
+- 🔵 **Новая фича / рефакторинг** → продолжай по `/start-task` (этот файл)
+- 🟢 **Багфикс** (> 2 файлов, нетривиальный) → переключись на `/bugfix`
+- 🟡 **Hotfix** (1–2 файла, blast radius ≈ 0) → переключись на `/hotfix`
+
+> Если выбран `/bugfix` или `/hotfix` — прекрати чтение этого файла и следуй выбранному workflow.
+
+## Шаг 1: Загрузить правила пайплайна
+
+Выполни `/pipeline-rules` — прочитай и подтверди ВСЕ правила ПЕРЕД началом работы.
+
+## Шаг 2: Инициализировать агентов
+Выполни `view_file` на `AGENTS.md` — подтверди список агентов и skills.
+
+## Шаг 3: Запустить Дирижёра
+Выполни `view_file` на `agents/conductor.md` — прочитай протокол и создай Master Checklist в `task.md`.
+
+## Шаг 4: Пройти каждый гейт СТРОГО по протоколу
+
+На КАЖДОМ гейте обязательно:
+1. `view_file` на `agents/<role>.md` — прочитать протокол агента
+2. Пройти КАЖДУЮ секцию протокола по порядку (не «схлопывать»)
+3. Использовать **полный** «Формат ответа агента (строго)» из файла агента
+4. Если секция не применима — явно написать: «N/A — [причина]»
+5. Сформировать deliverable + Handoff Envelope со ВСЕМИ обязательными полями
+6. Представить результат через `notify_user`
+7. **Ждать явный "Approved"** перед переходом к следующему гейту
+
+## Шаг 5: Код — ТОЛЬКО после DEV gate + Approved
+
+- Сначала DEV-агент проходит ВСЕ секции протокола (§0–§7)
+- Потом предлагает план изменений
+- Пользователь одобряет
+- ТОЛЬКО ПОТОМ агент применяет код
+
+## Шаг 6: Fix Cycle (при FAIL)
+
+Если тестер или ревьюер нашёл баг:
+1. Текущий агент выдаёт FAIL Report + HANDOFF Envelope → DEV
+2. Пользователь одобряет FAIL HANDOFF
+3. DEV читает `agents/senior_full_stack.md` и проходит ПОЛНЫЙ протокол
+4. DEV HANDOFF → REV → OPS → TEST (каждый гейт с полным протоколом)
+5. Никаких «быстрых фиксов» без прохода через агентов
+
+---
+
+## Шаблон первого промпта (копируй и заполни)
+
+```
+@AGENTS.md /pipeline-rules
+
+Задача: [что сделать, 1-2 предложения].
+Файлы: [конкретные файлы, если известны].
+
+Правила:
+1. Начинай с Дирижёра (agents/conductor.md)
+2. Каждый гейт: view_file → ВСЕ секции протокола → полный формат → Approved
+3. Код не применять до DEV gate + мой Approved
+4. Fix Cycle = полный проход через агентов
+```
+
+---
+
+## Рекомендации по сессиям
+
+- **Одна сессия = 3-4 гейта максимум** (контекст не теряется)
+- **Approved даётся на КАЖДОМ гейте**, не на сессию
+- **Сессия 1:** Conductor → Approved → PM → Approved → UX → Approved
+- **Сессия 2:** ARCH → Approved → DEV → Approved → REV → Approved
+- **Сессия 3:** OPS → Approved → TEST → Approved → RG → Approved
+- Каждая новая сессия — начинай с `/start-task`
+
+## Обязательные вопросы от агентов
+
+Каждый агент, у которого в протоколе есть Clarification/Questions секция, ОБЯЗАН:
+1. Задать вопросы пользователю ПЕРЕД выполнением работы
+2. Минимум вопросов (из протокола агента): PM — 5+, ARCH — 5-10, DEV — по необходимости, Tester — 5+
+3. Если задача кажется «очевидной» — всё равно задать минимум 2-3 уточняющих вопроса
+4. Ждать ответы пользователя ПЕРЕД продолжением
+5. Единственное исключение: пользователь явно написал «вопросов не задавай»
+
+## При «срезании углов» — одна фраза
+
+Если модель сокращает, скажи:
+> «Стоп. Секция [X] протокола agents/<role>.md. Перечитай и выполни.»
+
+---
+
+## Протокол обратной связи (обязательно)
+
+Модель ОБЯЗАНА предоставлять обратную связь пользователю на каждом этапе:
+
+### 1. Предупреждение при соблазне срезать
+Если задача выглядит «тривиальной», модель ОБЯЗАНА написать:
+```
+⚠️ Задача выглядит тривиальной. Мой инстинкт — сделать быстро.
+Но по протоколу прохожу полный цикл. Секции: [список].
+```
+
+### 2. Оценка промпта пользователя
+В начале каждой задачи модель оценивает промпт:
+```
+📊 Оценка промпта:
+- Чёткость: [высокая/средняя/низкая]
+- Что хорошо: [что помогло]
+- Чего не хватает: [что добавить для эффективности]
+```
+
+### 3. Подсказки в Handoff Envelope
+В каждом Handoff добавлять секцию:
+```
+💡 Feedback: [совет для пользователя, если есть]
+```
+
+### 4. Ретроспектива в конце сессии
+Перед завершением работы:
+```
+🔄 Ретроспектива:
+- Гейтов пройдено: X
+- Нарушений протокола: X
+- Что улучшить в следующей сессии: [рекомендация]
 ```

package/AGENTS.yaml

@@ -35,6 +35,7 @@ skills:
   - "deployment_ci_plan"
   - "design_intake"
   - "design_parity_review"
+  - "design_patterns_reference"
   - "design_systems"
   - "dev_reference_snippets"
   - "docker_kubernetes_architecture"

package/agents/orchestrator.claude.json

@@ -29,6 +29,7 @@
     "deployment_ci_plan",
     "design_intake",
     "design_parity_review",
+    "design_patterns_reference",
     "design_systems",
     "dev_reference_snippets",
     "docker_kubernetes_architecture",

package/agents/orchestrator.copilot.json

@@ -29,6 +29,7 @@
     "deployment_ci_plan",
     "design_intake",
     "design_parity_review",
+    "design_patterns_reference",
     "design_systems",
     "dev_reference_snippets",
     "docker_kubernetes_architecture",

package/agents/orchestrator.gemini.json

@@ -29,6 +29,7 @@
     "deployment_ci_plan",
     "design_intake",
     "design_parity_review",
+    "design_patterns_reference",
     "design_systems",
     "dev_reference_snippets",
     "docker_kubernetes_architecture",