code-ai-installer 1.5.0 → 1.5.2

package/.agents/skills/design_patterns_reference/agents/gemini.json

@@ -0,0 +1,19 @@
+{
+  "name": "design_patterns_reference",
+  "display_name": "Справочник паттернов проектирования",
+  "description": "Справочник паттернов проектирования с DO/DON'T примерами — SOLID, DRY/KISS/YAGNI, GoF (Strategy, Observer, Factory, Adapter, Facade, Decorator, Command, State, Template Method), архитектурные (Repository, Service Layer, DI, Event-Driven, CQRS), микросервисные (Saga, Circuit Breaker). Language-agnostic псевдокод. Используй при проектировании модулей, ревью архитектуры, или при вопросах «какой паттерн применить».",
+  "default_prompt": "Используй $design_patterns_reference, когда задача относится к навыку \"Справочник паттернов проектирования\".",
+  "triggers": [
+    "design_patterns_reference",
+    "design patterns reference",
+    "Справочник паттернов проектирования",
+    "Справочник паттернов проектирования с DO/DON'T примерами — SOLID, DRY/KISS/YAGNI, GoF (Strategy, Observer, Factory, Adapter, Facade, Decorator, Command, State, Template Method), архитектурные (Repository, Service Layer, DI, Event-Driven, CQRS), микросервисные (Saga, Circuit Breaker). Language-agnostic псевдокод. Используй при проектировании модулей, ревью архитектуры, или при вопросах «какой паттерн применить»."
+  ],
+  "capabilities": [
+    "architecture",
+    "design",
+    "patterns"
+  ],
+  "tools": [],
+  "implicit_invocation": true
+}

package/.agents/skills/design_patterns_reference/agents/skill.yaml

@@ -0,0 +1,23 @@
+version: 1
+name: "design_patterns_reference"
+display_name: "Справочник паттернов проектирования"
+description: "Справочник паттернов проектирования с DO/DON'T примерами — SOLID, DRY/KISS/YAGNI, GoF (Strategy, Observer, Factory, Adapter, Facade, Decorator, Command, State, Template Method), архитектурные (Repository, Service Layer, DI, Event-Driven, CQRS), микросервисные (Saga, Circuit Breaker). Language-agnostic псевдокод. Используй при проектировании модулей, ревью архитектуры, или при вопросах «какой паттерн применить»."
+default_prompt: "Используй $design_patterns_reference, когда задача относится к навыку \"Справочник паттернов проектирования\"."
+triggers:
+  - "design_patterns_reference"
+  - "design patterns reference"
+  - "Справочник паттернов проектирования"
+  - "Справочник паттернов проектирования с DO/DON'T примерами — SOLID, DRY/KISS/YAGNI, GoF (Strategy, Observer, Factory, Adapter, Facade, Decorator, Command, State, Template Method), архитектурные (Repository, Service Layer, DI, Event-Driven, CQRS), микросервисные (Saga, Circuit Breaker). Language-agnostic псевдокод. Используй при проектировании модулей, ревью архитектуры, или при вопросах «какой паттерн применить»."
+capabilities:
+  - "architecture"
+  - "design"
+  - "patterns"
+tools: []
+invocation:
+  explicit: true
+  implicit: true
+localization:
+  default_locale: "ru"
+  available_locales:
+    - "ru"
+    - "en"

package/.agents/workflows/bugfix.md

@@ -0,0 +1,90 @@
+---
+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

@@ -0,0 +1,74 @@
+---
+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,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 обновляется при изменении стека, паттернов или ограничений