code-ai-installer 4.0.1-b → 4.0.1

package/domains/development/.agents/workflows/hotfix.md

@@ -1,74 +1,24 @@
 ---
-description: Запуск минимального 2-гейтового пайплайна для мелких правок (hotfix). Используй для тривиальных фиксов с blast radius ≈ 0.
+description: Запуск минимального хотфикс-пайплайна (DEV фикс+тест → RG).
 ---
 
-# /hotfix — Запуск Hotfix Pipeline (2 гейта)
+# /hotfix — хотфикс-пайплайн (2 гейта)
 
-> 🟡 **Режим:** Hotfix — для тривиальных правок с минимальным риском.
-> Полный пайплайн: `/start-task`. Bugfix (серьёзнее): `/bugfix`.
+> 🟡 Для тривиальных правок, blast radius ≈ 0. Серьёзнее — `/bugfix`, полный — `/start-task`.
+> Абсолютные правила — в `pipeline-rules`.
 
-## Когда использовать
+## Когда
+- Опечатки, CSS-правки (цвет/отступ/размер), однострочная логика, копипаст-ошибка.
+- 1–2 файла, контракты не меняются.
 
-- Опечатки в тексте/коде
-- CSS-правки (цвет, отступ, размер)
-- Правка одной строки логики
-- Копипаст-ошибка
-- Blast radius ≈ 0 (затрагивает 1–2 файла, не меняет контракты)
+## НЕ использовать
+- > 2 файлов → `/bugfix`; меняет API-контракт → `/bugfix` или `/start-task`; меняет UI-layout/экраны → `/start-task`; не уверен → спросить пользователя.
 
-## НЕ использовать если
+## Поток
+Conductor подтверждает hotfix. Объединённый гейт **DEV (фикс+тест)** через поток MCP:
+- TDD при применимости (RED → GREEN → REFACTOR), JSDoc; самопроверка.
+- Авто-пас на зелёном `run_tests`; подпись `mcp` (co-sign tester).
+- → **RG** — финальный релиз, подпись **пользователя** (`user`).
 
-- Затрагивает > 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 предложение].
-Файл: [конкретный файл].
-```
+## При сомнении
+Если по ходу стало сложнее хотфикса: «Задача сложнее hotfix → рекомендую `/bugfix`». Переключение — решение пользователя.

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

@@ -1,163 +1,80 @@
 ---
-description: Абсолютные правила пайплайна разработки. ЗАПРЕЩЕНО НАРУШАТЬ.
+description: Абсолютные правила пайплайна разработки. Машина гейтов code-ai MCP.
 ---
 
-# 🔴 АБСОЛЮТНОЕ ПРАВИЛО: Пайплайн запрещено пропускать
+# 🔴 АБСОЛЮТНОЕ ПРАВИЛО: пайплайн нельзя пропускать
 
-**Это правило не имеет исключений. Нарушение = блокер.**
+**Без исключений. Нарушение = блокер.** Пайплайн исполняется машиной состояний `code-ai` MCP: источник правды — `pipeline.yaml`, переходы — через MCP-инструменты (см. ниже).
 
 ## Пайплайн — 3 режима
 
 ### 🔵 Full Pipeline (8 гейтов) — `/start-task`
-CONDUCTOR → PM → UX → ARCH → DEV → REV → OPS → TEST → RG
+PM → UX → ARCH → DEV → REV → OPS → TEST → RG
 
-### 🟢 Bugfix Pipeline (4 гейта) — `/bugfix`
-CONDUCTOR → DEV → REV → TEST
+### 🟢 Bugfix Pipeline (3 гейта) — `/bugfix`
+DEV → REV → TEST
 
 ### 🟡 Hotfix Pipeline (2 гейта) — `/hotfix`
-CONDUCTOR → DEV+TEST
+DEV (фикс+тест) → RG
+
+> CONDUCTOR — не гейт, а роль-оркестратор: классифицирует задачу, выбирает режим (Decision Tree ниже), новых скиллов не получает (использует `$board`, `$handoff`, `$gates`).
 
 ### Decision Tree (выбор режима)
 ```
-Задача от пользователя
-  │
-  ├─ Новая фича / рефакторинг / новый API / новый экран?
-  │    └─ 🔵 Full Pipeline
-  │
+Задача пользователя
+  ├─ Новая фича / рефакторинг / новый API / экран? → 🔵 Full
   ├─ Баг в существующем функционале?
-  │    ├─ Затрагивает > 2 файлов или меняет контракт API?
-  │    │    └─ 🟢 Bugfix (4 гейта)
-  │    ├─ Затрагивает 1–2 файла, blast radius ≈ 0?
-  │    │    └─ 🟡 Hotfix (2 гейта)
+  │    ├─ > 2 файлов или меняет контракт API? → 🟢 Bugfix
+  │    ├─ 1–2 файла, blast radius ≈ 0?        → 🟡 Hotfix
   │    └─ Не уверен → спросить пользователя
-  │
-  └─ Пользователь явно указал режим (/bugfix, /hotfix)?
-       └─ Использовать указанный
+  └─ Пользователь указал режим явно (/bugfix, /hotfix) → использовать его
 ```
 
-> Conductor **не получает новых skills** — использует существующие `$board`, `$handoff`, `$gates`.
+## Как проходит гейт (поток MCP)
 
-## Обязательные действия на КАЖДОМ гейте (все режимы)
+На каждом гейте, по порядку:
+1. `current_gate` — подтвердить текущий гейт и его требования.
+2. `classify_gate` — классифицировать исход: `auto_resolve` (можно двигаться), `fork` (нужно решение пользователя → `request_decision`), `exception` (сбой → `report_exception`).
+3. `load_role` на роль-владельца гейта → пройти её протокол по шагам; нужные скиллы загрузить через `get_skill`.
+4. Сформировать deliverable + `submit_artifact`.
+5. `sign_off` — подписать гейт по его политике (см. модель подписи).
+6. `advance_gate` — перейти к следующему гейту.
 
-1. `view_file` на `agents/<role>.md` — прочитать протокол агента
-2. Следовать **его** инструкциям, использовать **его** skills
-3. Сформировать deliverable + Handoff Envelope
-4. Представить результат пользователю через `notify_user`
-5. **Ждать явный "Approved" от пользователя** перед переходом к следующему гейту
+## 🟢 Модель подписи — silent-by-default (reduced intervention)
 
----
+Машина течёт молча; пользователя дёргаем только на решениях-суждениях.
 
-## 🛑 СТОП-ПРАВИЛА (перед каждым действием с кодом)
-
-### Правило 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?
+| Гейт | Кто подписывает | Как |
+|------|-----------------|-----|
+| PM / UX / ARCH | **Пользователь** (`user`) | важное решение: что и зачем строим |
+| DEV / REV | Claude (`mcp`) | по суждению агента (разработка / ревью) |
+| OPS / TEST | Claude (`mcp`) | после зелёного авто-чека: `build` (OPS), `run_tests` (TEST) |
+| RG | **Пользователь** (`user`) | финальный релиз |
 
----
+- К пользователю попадает только: гейты-суждения (PM/UX/ARCH/RG) и явная эскалация через `request_decision` (классификация `fork`).
+- Рутинные проходы пользователь не подтверждает.
 
-## Запрещено
+## 🔁 Красный, Fix Cycle и Circuit Breaker
 
-- ❌ «Fast-track» гейтов (пропуск нескольких гейтов за раз)
-- ❌ Интерпретировать «Подтверждаю» как разрешение пропустить гейты
-- ❌ Начинать пайплайн без явного разрешения пользователя
-- ❌ Переходить к следующему гейту без «Approved» от пользователя
-- ❌ Писать код (DEV gate) до прохождения предыдущих гейтов
-- ❌ Применять код до завершения полного протокола агента
-- ❌ Сокращать формат ответа (каждая секция обязательна)
-- ❌ Игнорировать параграфы протокола, считая задачу «тривиальной»
-- ❌ Врать о факте прочтения протокола (если не было `view_file` — значит не читал)
+- **Красный авто-чек** (OPS/TEST) или FAIL ревью/тестов → откат к **DEV** (Fix Cycle), не к пользователю. DEV чинит → снова вперёд по полосе.
+- **Circuit Breaker:** 2 отката к DEV на полосе DEV/OPS/REV/TEST (`dev_rollback_threshold`) → машина отказывает в продвижении и требует **глубокий аудит Архитектора в свежей сессии** (чистый контекст: тот же Claude, что упёрся в стену, воспроизведёт слепое пятно). Скиллы аудита: `system-design-checklist`, `current-state-analysis`, `design-patterns-reference`.
+- **Сброс счётчика:** на прохождении RG или на новом ARCH-ADR (`record_decision` на гейте ARCH).
 
----
+## ✅ Что обязательно (остаётся)
 
-## 🔒 МЕХАНИЧЕСКИЕ БЛОКИ
+- Гейты нельзя пропускать, объединять или менять порядок без явного решения пользователя.
+- У каждого гейта — конкретный deliverable; без него гейт не закрыт (проверка `$gates`).
+- Протокол роли проходится по шагам, не «схлопывая»; пропуск шага — с явной причиной.
+- TDD на DEV: RED → GREEN → REFACTOR.
+- Решения, влияющие на архитектуру/контракты, фиксируются ADR через `record_decision`.
 
-> Эти правила введены после инцидента, когда агент проигнорировал pipeline,
-> авто-одобрил ARCH gate, проигнорировал открытый вопрос пользователя,
-> написал код без TDD, и сдал нерабочий preview.
+## 📊 Touchpoint budget (сигнал здоровья)
 
-### Блок 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. Формальные галочки без реального чтения = нарушение = блокер
+Ориентир числа касаний пользователя по типу задачи (из `pipeline.yaml`): hotfix 1; bugfix 1–2; backend-фича 1–3; UI-фича с ARCH-развилкой 3–5; сложная (3+ Fix Cycle) 3–6. Превышение — повод пересмотреть scope, а не «продавливать».
 
----
+## ❌ Запрещено
 
-## Обязательные артефакты
-
-### 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 обновляется при изменении стека, паттернов или ограничений
+- Пропускать гейты или «фаст-трекать» несколько за раз.
+- Продвигать гейт без `sign_off` по его политике.
+- Писать код (DEV) до прохождения предыдущих гейтов и до плана.
+- Молча обходить откат/брейкер: 2 отката → аудит ARCH, а не «ещё одна попытка» в том же контексте.

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

@@ -1,130 +1,26 @@
 ---
-description: Шаблон запуска задачи через 8-агентный пайплайн. Используй в начале КАЖДОЙ сессии.
+description: Запуск задачи через полный пайплайн (8 гейтов). Машина гейтов code-ai MCP.
 ---
 
-# /start-task — Запуск задачи через пайплайн
+# /start-task — запуск полного пайплайна
 
-## Шаг 0: Выбрать режим пайплайна
+Полный режим: PM → UX → ARCH → DEV → REV → OPS → TEST → RG.
+Багфикс → `/bugfix`, мелкая правка (blast radius ≈ 0) → `/hotfix`.
+Абсолютные правила — в `pipeline-rules` (машина гейтов code-ai MCP).
 
-Определи тип задачи и выбери workflow:
-- 🔵 **Новая фича / рефакторинг** → продолжай по `/start-task` (этот файл)
-- 🟢 **Багфикс** (> 2 файлов, нетривиальный) → переключись на `/bugfix`
-- 🟡 **Hotfix** (1–2 файла, blast radius ≈ 0) → переключись на `/hotfix`
+## 1. Старт
+- Conductor классифицирует задачу и подтверждает режим (Decision Tree в `pipeline-rules`).
+- Conductor инициализирует доску (`$board`) и стартовый Handoff (`$handoff`). Новых скиллов не получает.
 
-> Если выбран `/bugfix` или `/hotfix` — прекрати чтение этого файла и следуй выбранному workflow.
+## 2. Каждый гейт — поток MCP
+`current_gate` → `classify_gate` → `load_role` (роль гейта) + `get_skill` → deliverable + `submit_artifact` → `sign_off` → `advance_gate`.
 
-## Шаг 1: Загрузить правила пайплайна
+## 3. Подпись — silent-by-default
+- **Пользователь подписывает только PM / UX / ARCH / RG** (решения-суждения) и эскалации `fork` через `request_decision`.
+- DEV / REV — Claude (`mcp`) по суждению; OPS / TEST — авто-пас на зелёном (`build` / `run_tests`).
 
-Выполни `/pipeline-rules` — прочитай и подтверди ВСЕ правила ПЕРЕД началом работы.
+## 4. Уточняющие вопросы
+Агенты с секцией Clarification (PM 5+, ARCH 5–10, Tester 5+) задают вопросы ПЕРЕД работой и ждут ответа. Исключение — пользователь написал «без вопросов».
 
-## Шаг 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
-- Что улучшить в следующей сессии: [рекомендация]
-```
+## 5. Fix Cycle / брейкер
+Красный (FAIL ревью/тестов, красный авто-чек) → откат к DEV. 2 отката на полосе DEV/OPS/REV/TEST → глубокий аудит Архитектора в свежей сессии (см. `pipeline-rules`).

package/domains/development/AGENTS.md

@@ -218,11 +218,16 @@ function add(a, b) {
 ---
 
 ## Обязательное правило перезагрузки Docker-контейнеров
-- Для всех изменений в кодовой базе DevOps обязан автоматически перезапускать затронутый сервис в Docker до передачи в REVIEW/TEST.
-- Базовое правило команд:
+- Для всех изменений в кодовой базе DevOps обязан автоматически перезапускать затронутый сервис в Docker до передачи в REVIEW/TEST. Это **неявное** правило — выполняется в рамках задачи, без отдельного запроса разрешения.
+- **Определение сервиса (не хардкодить имена из конкретного продукта):**
+  - Открыть активный Compose-файл (`docker-compose.yml`, `docker-compose.yaml`, `compose.yml` или `compose.yaml`).
+  - Определить владельца изменённого пути по `build.context`, bind-mount `volumes` и принятым в репозитории именам сервисов.
+  - Перезапускать имя **Compose-сервиса**, а не имя контейнера (имена контейнеров специфичны для проекта).
+- **Команды:**
   - Изменения только runtime-кода: `docker compose restart <service>`.
   - Изменения `Dockerfile`/зависимостей/сборки/compose-конфига: `docker compose up -d --build <service>`.
-- При изменениях в прокси/шлюзе/общей маршрутизации дополнительно перезапускать `gateway`.
+  - Несколько затронутых сервисов — одной командой: `docker compose restart <service_one> <service_two>`.
+- Изменения только инфраструктуры (`infra/`, compose-файлы, конфиг reverse-proxy) и изменения только конфига/env **не** триггерят перезапуск app-сервиса. При изменениях в прокси/шлюзе/общей маршрутизации дополнительно перезапускать `gateway`.
 - DevOps обязан приложить в отчёт доказательства:
   - какие сервисы перезапущены,
   - какие команды выполнены,