code-ai-installer 2.4.1 → 3.0.0

package/.agents/skills/wix-self-hosted-embedded-script/agents/qwen.json

@@ -1,21 +0,0 @@
-{
-  "name": "wix-self-hosted-embedded-script",
-  "display_name": "Самохостируемый встроенный скрипт для Wix",
-  "description": "Практический runbook для Wix Self-Hosted Embedded Script — HTTPS локально, install webhook, embed script, resolve appInstanceId, DB-driven widget config, частые ошибки и проверка DEMO-ready.",
-  "default_prompt": "Используй $wix-self-hosted-embedded-script, когда задача относится к навыку \"Самохостируемый встроенный скрипт для Wix\".",
-  "triggers": [
-    "wix-self-hosted-embedded-script",
-    "wix self hosted embedded script",
-    "Самохостируемый встроенный скрипт для Wix",
-    "Практический runbook для Wix Self-Hosted Embedded Script — HTTPS локально, install webhook, embed script, resolve appInstanceId, DB-driven widget config, частые ошибки и проверка DEMO-ready"
-  ],
-  "capabilities": [
-    "wix",
-    "self",
-    "hosted",
-    "embedded",
-    "script"
-  ],
-  "tools": [],
-  "implicit_invocation": true
-}

package/.agents/skills/wix-self-hosted-embedded-script/agents/skill.yaml

@@ -1,25 +0,0 @@
-version: 1
-name: "wix-self-hosted-embedded-script"
-display_name: "Самохостируемый встроенный скрипт для Wix"
-description: "Практический runbook для Wix Self-Hosted Embedded Script — HTTPS локально, install webhook, embed script, resolve appInstanceId, DB-driven widget config, частые ошибки и проверка DEMO-ready."
-default_prompt: "Используй $wix-self-hosted-embedded-script, когда задача относится к навыку \"Самохостируемый встроенный скрипт для Wix\"."
-triggers:
-  - "wix-self-hosted-embedded-script"
-  - "wix self hosted embedded script"
-  - "Самохостируемый встроенный скрипт для Wix"
-  - "Практический runbook для Wix Self-Hosted Embedded Script — HTTPS локально, install webhook, embed script, resolve appInstanceId, DB-driven widget config, частые ошибки и проверка DEMO-ready"
-capabilities:
-  - "wix"
-  - "self"
-  - "hosted"
-  - "embedded"
-  - "script"
-tools: []
-invocation:
-  explicit: true
-  implicit: true
-localization:
-  default_locale: "ru"
-  available_locales:
-    - "ru"
-    - "en"

package/.agents/workflows/auto-restart-containers.md

@@ -1,56 +0,0 @@
----
-description: Auto-restart affected Docker containers after code changes
----
-
-# Auto-Restart Affected Containers
-
-After **any code change** to a file inside one of the application source directories, the corresponding Docker service **must be restarted** automatically without asking the user.
-
-## Source -> Service Mapping
-
-Do not hardcode service or container names from a specific product.
-
-For the current repository:
-
-1. Inspect the active Docker Compose file (`docker-compose.yml`, `docker-compose.yaml`, `compose.yml`, or `compose.yaml`).
-2. Identify which service owns the changed source path by checking:
-   - `build.context`
-   - bind-mounted `volumes`
-   - existing service naming conventions in the repo
-3. Restart the matching Compose service name, not a project-specific container name.
-
-Infrastructure-only changes (`infra/`, compose files, reverse proxy config) do **not** trigger an app-service restart by this workflow.
-Config/env-only changes do **not** trigger an app-service restart by this workflow.
-
-## Steps
-
-1. After editing file(s), determine which app or package directory was affected.
-2. Map that path to the Docker Compose service for the current project.
-3. Run the restart command:
-
-// turbo
-```
-docker compose restart <service_name>
-```
-
-Example: if `apps/frontend/src/components/SomeComponent.jsx` belongs to the `frontend` service:
-```
-docker compose restart frontend
-```
-
-4. If **multiple** services were affected, restart all of them in one command:
-
-// turbo
-```
-docker compose restart <service_one> <service_two>
-```
-
-5. Do **not** ask the user for permission - this is a turbo step.
-6. Wait for the restart to complete before reporting results.
-
-## Important Notes
-
-- The working directory for `docker compose` must be the project root that contains the active Compose file.
-- Use Compose service names, not Docker container names, because container names are project-specific.
-- Shared infrastructure services such as a gateway, proxy, or database usually do **not** need restart for ordinary app-level code changes unless the edited files directly affect them.
-- This workflow is **implicit** - it runs as part of any development task, not as a standalone action.

package/.agents/workflows/bugfix.md

@@ -1,90 +0,0 @@
----
-description: Запуск сокращённого 4-гейтового пайплайна для исправления багов. Используй вместо /start-task для bugfix-задач.
----
-
-# /bugfix — Запуск Bugfix Pipeline (4 гейта)
-
-> 🟢 **Режим:** Bugfix — для исправления багов в существующем функционале.
-> Полный пайплайн: `/start-task`. Hotfix (мелочи): `/hotfix`.
-
-## Когда использовать
-
-- Баг в логике, API ошибки, сломанная валидация, проблемы с данными
-- Затрагивает > 2 файлов или нетривиальный blast radius
-- НЕ меняет UI layout, НЕ добавляет новый API, НЕ меняет схему данных (иначе → `/start-task`)
-
-## Шаг 0: Загрузить правила
-
-Выполни `/pipeline-rules` — прочитай правила ПЕРЕД началом работы.
-
-## Шаг 1: CONDUCTOR — Классификация
-
-1. Выполни `view_file` на `agents/conductor.md`
-2. Подтверди что задача = bugfix (по Decision Tree)
-3. Создай Mini Checklist:
-```
-[ ] BF-DEV-01   Fix + TDD + Handoff Envelope
-[ ] BF-REV-01   Code review + regression check + Handoff Envelope
-[ ] BF-TEST-01  Verification + regression smoke + GO/NO-GO
-```
-4. `notify_user` → ждать **Approved**
-
-## Шаг 2: DEV — TDD-фикс
-
-1. Выполни `view_file` на `agents/senior_full_stack.md`
-2. Пройди протокол (пропуская §1 UX review и §6 DEMO):
-   - §0: Context + read skills
-   - §2: Analyze bug + root cause
-   - §3: RED — написать падающий тест, воспроизводящий баг
-   - §4: GREEN — минимальный код для прохождения теста
-   - §5: REFACTOR — улучшить без изменения поведения
-   - §7: JSDoc на изменённых функциях
-3. Перезапустить затронутые сервисы (если применимо)
-4. Сформировать Handoff Envelope → REV
-5. `notify_user` → ждать **Approved**
-
-## Шаг 3: REV — Code Review
-
-1. Выполни `view_file` на `agents/reviewer.md`
-2. Фокус ревью:
-   - Тест действительно воспроизводит баг (RED-фаза)?
-   - Фикс не создаёт побочных эффектов?
-   - Regression risk оценён?
-   - JSDoc на месте?
-3. Сформировать Handoff Envelope → TEST
-4. `notify_user` → ждать **Approved**
-
-## Шаг 4: TEST — Верификация
-
-1. Выполни `view_file` на `agents/tester.md`
-2. Проверить:
-   - Баг исправлен (по шагам воспроизведения)
-   - Регрессии нет (smoke по затронутым модулям)
-   - Тесты проходят (CI green)
-3. Вынести вердикт: **GO ✅ / NO-GO ❌**
-4. `notify_user` → ждать **Approved**
-
----
-
-## При FAIL на REV или TEST
-
-1. Агент выдаёт FAIL Report + Handoff → DEV
-2. DEV исправляет → Handoff → REV → TEST (повтор цикла)
-3. Approved на каждом гейте обязателен
-
----
-
-## Шаблон промпта
-
-```
-@AGENTS.md /bugfix
-
-Баг: [описание бага, 1-2 предложения].
-Воспроизведение: [шаги, если известны].
-Файлы: [затронутые файлы, если известны].
-
-Правила:
-1. Bugfix Pipeline: CONDUCTOR → DEV → REV → TEST
-2. TDD обязательно (RED → GREEN → REFACTOR)
-3. Approved на каждом гейте
-```

package/.agents/workflows/hotfix.md

@@ -1,74 +0,0 @@
----
-description: Запуск минимального 2-гейтового пайплайна для мелких правок (hotfix). Используй для тривиальных фиксов с blast radius ≈ 0.
----
-
-# /hotfix — Запуск Hotfix Pipeline (2 гейта)
-
-> 🟡 **Режим:** Hotfix — для тривиальных правок с минимальным риском.
-> Полный пайплайн: `/start-task`. Bugfix (серьёзнее): `/bugfix`.
-
-## Когда использовать
-
-- Опечатки в тексте/коде
-- CSS-правки (цвет, отступ, размер)
-- Правка одной строки логики
-- Копипаст-ошибка
-- Blast radius ≈ 0 (затрагивает 1–2 файла, не меняет контракты)
-
-## НЕ использовать если
-
-- Затрагивает > 2 файлов → `/bugfix`
-- Меняет API контракт → `/bugfix` или `/start-task`
-- Меняет UI layout / добавляет экраны → `/start-task`
-- Не уверен → спросить пользователя
-
-## Шаг 0: Загрузить правила
-
-Выполни `/pipeline-rules` — прочитай правила ПЕРЕД началом работы.
-
-## Шаг 1: CONDUCTOR — Классификация
-
-1. Выполни `view_file` на `agents/conductor.md`
-2. Подтверди что задача = hotfix (по Decision Tree: blast radius ≈ 0, 1–2 файла)
-3. Создай Mini Checklist:
-```
-[ ] HF-DEV-01   Fix + test + перезапуск сервиса (если применимо)
-[ ] HF-VERIFY   Self-check + GO/NO-GO
-```
-4. `notify_user` → ждать **Approved**
-
-## Шаг 2: DEV+TEST — Фикс и самопроверка
-
-1. Выполни `view_file` на `agents/senior_full_stack.md`
-2. TDD:
-   - RED: тест, воспроизводящий проблему (если применимо)
-   - GREEN: минимальный фикс
-   - REFACTOR: при необходимости
-3. JSDoc на изменённых функциях
-4. Перезапустить затронутые сервисы (если применимо)
-5. Самопроверка:
-   - Фикс работает?
-   - Тесты проходят?
-   - Регрессий нет?
-6. Вердикт: **GO ✅ / NO-GO ❌**
-7. `notify_user` → ждать **Approved**
-
----
-
-## При сомнениях
-
-Если во время работы стало ясно, что задача сложнее чем hotfix:
-> ⚠️ «Задача оказалась сложнее hotfix. Рекомендую переключиться на /bugfix.»
-
-Переключение — только с Approved пользователя.
-
----
-
-## Шаблон промпта
-
-```
-@AGENTS.md /hotfix
-
-Что исправить: [описание, 1 предложение].
-Файл: [конкретный файл].
-```

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

@@ -1,163 +0,0 @@
----
-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,130 +0,0 @@
----
-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
-- Что улучшить в следующей сессии: [рекомендация]
-```