code-ai-installer 1.5.1 → 1.5.2

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/locales/en/.agents/workflows/bugfix.md

@@ -0,0 +1,90 @@
+---
+description: Launch the shortened 4-gate pipeline for bug fixes. Use instead of /start-task for bugfix tasks.
+---
+
+# /bugfix — Launch Bugfix Pipeline (4 gates)
+
+> 🟢 **Mode:** Bugfix — for fixing bugs in existing functionality.
+> Full pipeline: `/start-task`. Hotfix (trivial): `/hotfix`.
+
+## When to use
+
+- Bug in logic, API errors, broken validation, data issues
+- Affects > 2 files or non-trivial blast radius
+- Does NOT change UI layout, does NOT add new API, does NOT change data schema (otherwise → `/start-task`)
+
+## Step 0: Load rules
+
+Execute `/pipeline-rules` — read the rules BEFORE starting work.
+
+## Step 1: CONDUCTOR — Classification
+
+1. Execute `view_file` on `agents/conductor.md`
+2. Confirm the task = bugfix (per Decision Tree)
+3. Create 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` → wait for **Approved**
+
+## Step 2: DEV — TDD Fix
+
+1. Execute `view_file` on `agents/senior_full_stack.md`
+2. Follow the protocol (skipping §1 UX review and §6 DEMO):
+   - §0: Context + read skills
+   - §2: Analyze bug + root cause
+   - §3: RED — write a failing test reproducing the bug
+   - §4: GREEN — minimal code to make the test pass
+   - §5: REFACTOR — improve without changing behavior
+   - §7: JSDoc on modified functions
+3. Restart affected services if applicable
+4. Form Handoff Envelope → REV
+5. `notify_user` → wait for **Approved**
+
+## Step 3: REV — Code Review
+
+1. Execute `view_file` on `agents/reviewer.md`
+2. Review focus:
+   - Does the test actually reproduce the bug (RED phase)?
+   - Does the fix create side effects?
+   - Is regression risk assessed?
+   - Is JSDoc in place?
+3. Form Handoff Envelope → TEST
+4. `notify_user` → wait for **Approved**
+
+## Step 4: TEST — Verification
+
+1. Execute `view_file` on `agents/tester.md`
+2. Verify:
+   - Bug is fixed (per reproduction steps)
+   - No regression (smoke on affected modules)
+   - Tests pass (CI green)
+3. Issue verdict: **GO ✅ / NO-GO ❌**
+4. `notify_user` → wait for **Approved**
+
+---
+
+## On FAIL at REV or TEST
+
+1. Agent produces FAIL Report + Handoff → DEV
+2. DEV fixes → Handoff → REV → TEST (cycle repeats)
+3. Approved is required at every gate
+
+---
+
+## Prompt template
+
+```
+@AGENTS.md /bugfix
+
+Bug: [bug description, 1-2 sentences].
+Reproduction: [steps, if known].
+Files: [affected files, if known].
+
+Rules:
+1. Bugfix Pipeline: CONDUCTOR → DEV → REV → TEST
+2. TDD is mandatory (RED → GREEN → REFACTOR)
+3. Approved at every gate
+```

package/locales/en/.agents/workflows/hotfix.md

@@ -0,0 +1,74 @@
+---
+description: Launch the minimal 2-gate pipeline for trivial fixes (hotfix). Use for trivial fixes with blast radius ≈ 0.
+---
+
+# /hotfix — Launch Hotfix Pipeline (2 gates)
+
+> 🟡 **Mode:** Hotfix — for trivial fixes with minimal risk.
+> Full pipeline: `/start-task`. Bugfix (more serious): `/bugfix`.
+
+## When to use
+
+- Typos in text/code
+- CSS fixes (color, padding, font size)
+- Single-line logic fix
+- Copy-paste error
+- Blast radius ≈ 0 (affects 1–2 files, does not change contracts)
+
+## Do NOT use if
+
+- Affects > 2 files → `/bugfix`
+- Changes API contract → `/bugfix` or `/start-task`
+- Changes UI layout / adds screens → `/start-task`
+- Unsure → ask the user
+
+## Step 0: Load rules
+
+Execute `/pipeline-rules` — read the rules BEFORE starting work.
+
+## Step 1: CONDUCTOR — Classification
+
+1. Execute `view_file` on `agents/conductor.md`
+2. Confirm the task = hotfix (per Decision Tree: blast radius ≈ 0, 1–2 files)
+3. Create Mini Checklist:
+```
+[ ] HF-DEV-01   Fix + test + service restart (if applicable)
+[ ] HF-VERIFY   Self-check + GO/NO-GO
+```
+4. `notify_user` → wait for **Approved**
+
+## Step 2: DEV+TEST — Fix and self-verification
+
+1. Execute `view_file` on `agents/senior_full_stack.md`
+2. TDD:
+   - RED: test reproducing the issue (if applicable)
+   - GREEN: minimal fix
+   - REFACTOR: if necessary
+3. JSDoc on modified functions
+4. Restart affected services if applicable
+5. Self-verification:
+   - Does the fix work?
+   - Do tests pass?
+   - No regressions?
+6. Verdict: **GO ✅ / NO-GO ❌**
+7. `notify_user` → wait for **Approved**
+
+---
+
+## When in doubt
+
+If during work it becomes clear that the task is more complex than a hotfix:
+> ⚠️ "Task turned out to be more complex than a hotfix. Recommend switching to /bugfix."
+
+Switching — only with user Approved.
+
+---
+
+## Prompt template
+
+```
+@AGENTS.md /hotfix
+
+What to fix: [description, 1 sentence].
+File: [specific file].
+```

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

@@ -1,24 +1,163 @@
----
-description: Absolute development pipeline rules. MUST NOT BE BROKEN.
 ---
+description: Absolute development pipeline rules. MUST NOT be violated.
+---
+
+# 🔴 ABSOLUTE RULE: Pipeline must not be skipped
+
+**This rule has no exceptions. Violation = blocker.**
+
+## Pipeline — 3 Modes
+
+### 🔵 Full Pipeline (8 gates) — `/start-task`
+CONDUCTOR → PM → UX → ARCH → DEV → REV → OPS → TEST → RG
 
-# Pipeline Rules
+### 🟢 Bugfix Pipeline (4 gates) — `/bugfix`
+CONDUCTOR → DEV → REV → TEST
 
-The pipeline must not be skipped.
+### 🟡 Hotfix Pipeline (2 gates) — `/hotfix`
+CONDUCTOR → DEV+TEST
 
-## Pipeline
-TEST → PM → UX → ARCH → DEV → REV → OPS → TEST
+### Decision Tree (mode selection)
+```
+User task
+  │
+  ├─ New feature / refactoring / new API / new screen?
+  │    └─ 🔵 Full Pipeline
+  │
+  ├─ Bug in existing functionality?
+  │    ├─ Affects > 2 files or changes API contract?
+  │    │    └─ 🟢 Bugfix (4 gates)
+  │    ├─ Affects 1–2 files, blast radius ≈ 0?
+  │    │    └─ 🟡 Hotfix (2 gates)
+  │    └─ Unsure → ask the user
+  │
+  └─ User explicitly specified mode (/bugfix, /hotfix)?
+       └─ Use the specified mode
+```
 
-## Mandatory actions at every gate
-1. Read `agents/<role>.md`
-2. Follow that role protocol and its skills
+> Conductor **does not receive new skills** — uses existing `$board`, `$handoff`, `$gates`.
+
+## Mandatory actions on EVERY gate (all modes)
+
+1. `view_file` on `agents/<role>.md` — read the agent protocol
+2. Follow **its** instructions, use **its** skills
 3. Produce deliverable + Handoff Envelope
-4. Present result to the user
-5. Wait for explicit `Approved` before moving forward
-
-## Forbidden
-- Fast-tracking gates
-- Writing code before the required gates are complete
-- Skipping mandatory protocol sections
-- Treating generic confirmation as permission to skip gates
-- Claiming a protocol was read when it was not
+4. Present the result to the user via `notify_user`
+5. **Wait for explicit "Approved" from the user** before moving to the next gate
+
+---
+
+## 🛑 STOP RULES (before any code action)
+
+### Rule 1: Agent protocol — step by step, no collapsing
+Each paragraph (§) in the agent file = **a separate step**.
+- Agent MUST pass ALL paragraphs in the order specified in the file
+- Collapsing multiple §§ into a single response is forbidden
+- If agent skips a §, it MUST state the reason: "§X skipped: [reason]"
+
+### Rule 2: Code is applied ONLY after full protocol pass
+- ❌ Must not: write code first → then write the report
+- ✅ Must: pass all §§ of the protocol → present plan → Approved → apply code
+
+### Rule 3: Full response format — no shortcuts
+- Use **"Agent Response Format (strict)"** from the agent file
+- Every section of the format is MANDATORY — skipping = violation
+- If a section is not applicable, explicitly write: "N/A — [reason]"
+
+### Rule 4: Fix Cycle — full pass through agents
+On FAIL at any gate:
+1. Current agent (e.g. Tester) produces FAIL Report + HANDOFF Envelope → DEV
+2. DEV reads `agents/senior_full_stack.md` and passes FULL protocol (§0–§7)
+3. DEV HANDOFF → REV → OPS → TEST (each gate with view_file + protocol + Approved)
+4. No "quick fixes" without passing through agents
+
+### Rule 5: Self-check before notify_user
+Before each `notify_user` the agent MUST internally verify:
+- [ ] Did I read the agent file (`view_file` on `agents/<role>.md`)?
+- [ ] Did I pass ALL paragraphs of the protocol?
+- [ ] Am I using the FULL response format?
+- [ ] Is there a HANDOFF Envelope with ALL mandatory fields?
+- [ ] Did I NOT apply code before receiving Approved?
+
+---
+
+## Prohibited
+
+- ❌ "Fast-tracking" gates (skipping multiple gates at once)
+- ❌ Interpreting "Confirmed" as permission to skip gates
+- ❌ Starting the pipeline without explicit user permission
+- ❌ Moving to the next gate without "Approved" from the user
+- ❌ Writing code (DEV gate) before passing prior gates
+- ❌ Applying code before completing the full agent protocol
+- ❌ Shortening the response format (every section is mandatory)
+- ❌ Ignoring protocol paragraphs, considering the task "trivial"
+- ❌ Lying about reading the protocol (if no `view_file` — it was not read)
+
+---
+
+## 🔒 MECHANICAL BLOCKS
+
+> These rules were introduced after an incident where the agent ignored the pipeline,
+> auto-approved the ARCH gate, ignored an open user question,
+> wrote code without TDD, and delivered a broken preview.
+
+### Block 1: ShouldAutoProceed = false ALWAYS
+```
+notify_user → ShouldAutoProceed: false
+```
+No exceptions. On EVERY notify_user. Even on "trivial" gates.
+Even if the agent is "confident". The user ALWAYS decides.
+
+### Block 2: Pre-flight check before ANY write_to_file / replace_file_content
+Before every code-writing tool call the agent MUST:
+1. Quote the LAST user message containing the word "Approved"
+2. If there is no quote — CODE MUST NOT BE WRITTEN
+3. System-generated messages are NOT considered "Approved"
+4. Auto-proceeded artifacts are NOT considered "Approved"
+
+### Block 3: Answering a question — quoting is mandatory
+If the agent asked the user a question:
+1. The agent's next response MUST start with: `> Your answer: [exact quote]`
+2. If there is no quote — no answer was given — STOP, repeat the question
+3. Guessing the answer for the user is forbidden
+4. Accepting a system-generated message as an answer is forbidden
+
+### Block 4: Strict TDD (DEV gate)
+1. RED: write FAILING tests FIRST
+2. GREEN: minimal code to make tests pass
+3. REFACTOR: improve code without changing behavior
+4. Writing code before tests = violation = blocker
+
+### Block 5: Skills — mandatory reading via view_file
+Each agent (`agents/<role>.md`) references skills in `.agents/skills/`.
+1. Agent MUST execute `view_file` on `SKILL.md` of EVERY skill referenced in the agent protocol
+2. If there was no `view_file` — the skill is NOT considered applied
+3. Patterns, anti-patterns, code examples, best practices from skills — mandatory for application
+4. In the deliverable the agent MUST state: `Skills applied: [list]` with `view_file` confirmation
+5. Formal checkmarks without actual reading = violation = blocker
+
+---
+
+## Mandatory artifacts
+
+### task.md (Antigravity brain — automatic)
+- **Created by:** Conductor at Gate 0
+- **Updated by:** EVERY agent after completing their gate
+- **Contains:** Master Checklist + Handoff Envelopes Status + Fix Cycle tracking
+- **Rule:** If task.md is not updated after a gate — the gate is not considered complete
+
+### implementation_plan.md
+- **Created by:** Architect at Gate 3 (ARCH) — or Conductor, if the task does not require ARCH
+- **Saved to:** `docs/reports/architect/plan-<task-name>.md` (in the project)
+- **Contains:** Proposed Changes + files + Verification Plan
+- **Rule:** DEV must read the plan before starting implementation. Reviewer references it during code review.
+
+### walkthrough.md (Antigravity brain — automatic)
+- **Created by:** Tester at Gate 7 (TEST) — or Release Gate
+- **Contains:** what was done, what was verified, validation results
+- **Rule:** update on each Fix Cycle and before Release Gate
+
+### docs/architecture.md + docs/ADR-log.md (in the project)
+- **Updated by:** Architect on any architectural decision
+- **Referenced by:** Reviewer and Architect on each gate
+- **Rule:** New ADRs are added to ADR-log.md. Architecture.md is updated when the stack, patterns, or constraints change