speccrew 0.5.10 → 0.5.12

package/docs/GETTING-STARTED.uk.md

@@ -1,4 +1,4 @@
-# SpecCrew - Посібник Швидкого Запуску
+# Посібник швидкого запуску SpecCrew
 
 <p align="center">
   <a href="./GETTING-STARTED.md">简体中文</a> |
@@ -11,11 +11,10 @@
   <a href="./GETTING-STARTED.it.md">Italiano</a> |
   <a href="./GETTING-STARTED.da.md">Dansk</a> |
   <a href="./GETTING-STARTED.ja.md">日本語</a> |
-  <a href="./GETTING-STARTED.ar.md">العربية</a> |
-  <a href="./GETTING-STARTED.uk.md">Українська</a>
+  <a href="./GETTING-STARTED.ar.md">العربية</a>
 </p>
 
-Цей документ допоможе вам швидко зрозуміти, як використовувати команду Агентів SpecCrew для завершення повного циклу розробки від вимог до доставки, дотримуючись стандартних інженерних процесів.
+Цей документ допоможе вам швидко зрозуміти, як використовувати команду Agent SpecCrew для завершення повної розробки від вимог до поставки відповідно до стандартних інженерних процесів.
 
 ---
 
@@ -27,7 +26,7 @@
 npm install -g speccrew
 ```
 
-### Ініціалізація Проекту
+### Ініціалізація проекту
 
 ```bash
 speccrew init --ide qoder
@@ -35,76 +34,151 @@ speccrew init --ide qoder
 
 Підтримувані IDE: `qoder`, `cursor`, `claude`, `codex`
 
-### Структура Каталогів Після Ініціалізації
+### Структура каталогів після ініціалізації
 
 ```
 .
 ├── .qoder/
-│   ├── agents/          # Файли визначення Агентів
-│   └── skills/          # Файли визначення Навичок
-├── speccrew-workspace/  # Робочий простір
+│   ├── agents/          # Файли визначення Agents
+│   └── skills/          # Файли визначення Skills
+├── speccrew-workspace/  # Workspace
 │   ├── docs/            # Конфігурації, правила, шаблони, рішення
 │   ├── iterations/      # Поточні ітерації
 │   ├── iteration-archives/  # Архівовані ітерації
 │   └── knowledges/      # База знань
-│       ├── base/        # Базова інформація (діагностичні звіти, технічні борги)
+│       ├── base/        # Базова інформація (звіти діагностики, технічний борг)
 │       ├── bizs/        # Бізнес-база знань
 │       └── techs/       # Технічна база знань
 ```
 
-### Довідник Команд CLI
+### Коротка довідка командам CLI
 
 | Команда | Опис |
-|---------|-------------|
-| `speccrew list` | Список усіх доступних Агентів та Навичок |
+|------|------|
+| `speccrew list` | Список всіх доступних Agents та Skills |
 | `speccrew doctor` | Перевірка цілісності встановлення |
 | `speccrew update` | Оновлення конфігурації проекту до останньої версії |
 | `speccrew uninstall` | Видалення SpecCrew |
 
 ---
 
-## 2. Огляд Робочого Процесу
+## 2. Швидкий старт за 5 хвилин після встановлення
 
-### Повна Діаграма Потоку
+Після виконання `speccrew init` виконайте наступні кроки для швидкого переходу в робочий стан:
+
+### Крок 1: Оберіть вашу IDE
+
+| IDE | Команда ініціалізації | Сценарій застосування |
+|-----|-----------|----------|
+| **Qoder** (Рекомендується) | `speccrew init --ide qoder` | Повна оркестрація агентів, паралельні workers |
+| **Cursor** | `speccrew init --ide cursor` | Робочі процеси на основі Composer |
+| **Claude Code** | `speccrew init --ide claude` | Розробка CLI-first |
+| **Codex** | `speccrew init --ide codex` | Інтеграція екосистеми OpenAI |
+
+### Крок 2: Ініціалізація бази знань (Рекомендується)
+
+Для проектів з існуючим вихідним кодом рекомендується спочатку ініціалізувати базу знань, щоб агенти розуміли вашу кодову базу:
+
+```
+@speccrew-team-leader ініціалізувати технічну базу знань
+```
+
+Потім:
+
+```
+@speccrew-team-leader ініціалізувати бізнес-базу знань
+```
+
+### Крок 3: Почніть ваше перше завдання
+
+```
+@speccrew-product-manager У мене нова вимога: [опишіть вашу функціональну вимогу]
+```
+
+> **Порада**: Якщо ви не впевнені, що робити, просто скажіть `@speccrew-team-leader допоможіть мені почати` — Team Leader автоматично визначить статус вашого проекту і направить вас.
+
+---
+
+## 3. Швидке дерево рішень
+
+Не впевнені, що робити? Знайдіть ваш сценарій нижче:
+
+- **У мене нова функціональна вимога**
+  → `@speccrew-product-manager У мене нова вимога: [опишіть вашу функціональну вимогу]`
+
+- **Я хочу сканувати знання існуючого проекту**
+  → `@speccrew-team-leader ініціалізувати технічну базу знань`
+  → Потім: `@speccrew-team-leader ініціалізувати бізнес-базу знань`
+
+- **Я хочу продовжити попередню роботу**
+  → `@speccrew-team-leader який поточний прогрес?`
+
+- **Я хочу перевірити стан здоров'я системи**
+  → Виконати в терміналі: `speccrew doctor`
+
+- **Я не впевнений, що робити**
+  → `@speccrew-team-leader допоможіть мені почати`
+  → Team Leader автоматично визначить статус вашого проекту і направить вас
+
+---
+
+## 4. Коротка довідка по Agents
+
+| Роль | Agent | Обов'язки | Приклад команди |
+|------|-------|-----------------|-----------------|
+| Лідер команди | `@speccrew-team-leader` | Навігація по проекту, ініціалізація бази знань, перевірка статусу | "Допоможіть мені почати" |
+| Менеджер продукту | `@speccrew-product-manager` | Аналіз вимог, генерація PRD | "У мене нова вимога: ..." |
+| Дизайнер функцій | `@speccrew-feature-designer` | Аналіз функцій, проектування специфікацій, API контракти | "Почати проектування функцій для ітерації X" |
+| Системний дизайнер | `@speccrew-system-designer` | Проектування архітектури, детальне проектування платформи | "Почати системне проектування для ітерації X" |
+| Системний розробник | `@speccrew-system-developer` | Координація розробки, генерація коду | "Почати розробку для ітерації X" |
+| Менеджер тестування | `@speccrew-test-manager` | Планування тестування, проектування випадків, виконання | "Почати тестування для ітерації X" |
+
+> **Примітка**: Вам не потрібно запам'ятовувати всіх агентів. Просто поговоріть з `@speccrew-team-leader`, і він направить ваш запит до правильного агента.
+
+---
+
+## 5. Огляд робочого процесу
+
+### Повна діаграма потоку
 
 ```mermaid
 flowchart LR
-    PRD[Етап 1<br/>Аналіз Вимог<br/>Product Manager] --> FD[Етап 2<br/>Проектування Функцій<br/>Feature Designer]
-    FD --> SD[Етап 3<br/>Проектування Системи<br/>System Designer]
-    SD --> DEV[Етап 4<br/>Розробка<br/>System Developer]
-    DEV --> TEST[Етап 5<br/>Тестування Системи<br/>Test Manager]
-    TEST --> ARCHIVE[Етап 6<br/>Архівування]
+    PRD[Фаза 1<br/>Аналіз вимог<br/>Product Manager] --> FD[Фаза 2<br/>Feature Design<br/>Feature Designer]
+    FD --> SD[Фаза 3<br/>System Design<br/>System Designer]
+    SD --> DEV[Фаза 4<br/>Розробка<br/>System Developer]
+    DEV --> TEST[Фаза 5<br/>Системне тестування<br/>Test Manager]
+    TEST --> ARCHIVE[Фаза 6<br/>Архівування]
     
-    KB[(База Знань<br/>Протягом Усього Процесу)] -.-> PRD
+    KB[(База знань<br/>Весь процес)] -.-> PRD
     KB -.-> FD
     KB -.-> SD
     KB -.-> DEV
     KB -.-> TEST
 ```
 
-### Базові Принципи
+### Основні принципи
 
-1. **Залежності Етапів**: Результат кожного етапу є вхідними даними для наступного етапу
-2. **Підтвердження Контрольної Точки**: Кожен етап має точку підтвердження, яка вимагає затвердження користувача перед продовженням
-3. **Керування Базою Знань**: База знань проходить через весь процес, надаючи контекст для всіх етапів
+1. **Залежності фаз**: Результат кожної фази є входом для наступної фази
+2. **Підтвердження checkpoint**: Кожна фаза має точку підтвердження, що вимагає затвердження користувача перед переходом до наступної фази
+3. **Керовано базою знань**: База знань проходить через весь процес, надаючи контекст для всіх фаз
 
 ---
 
-## 3. Нульовий Крок: Ініціалізація Бази Знань
+## 6. Крок нуль: Ініціалізація бази знань
 
 Перед початком формального інженерного процесу необхідно ініціалізувати базу знань проекту.
 
-### 3.1 Ініціалізація Технічної Бази Знань
+### 6.1 Ініціалізація технічної бази знань
 
-**Приклад Діалогу**:
+**Приклад розмови**:
 ```
 @speccrew-team-leader ініціалізувати технічну базу знань
 ```
 
-**Триетапний Процес**:
-1. Виявлення Платформи — Ідентифікація технологічних платформ у проекті
-2. Генерація Технічної Документації — Створення документів технічних специфікацій для кожної платформи
-3. Генерація Індексу — Створення індексу бази знань
+**Трьофазний процес**:
+1. Виявлення платформи — Ідентифікація технічних платформ в проекті
+2. Генерація технічної документації — Генерація документів технічних специфікацій для кожної платформи
+3. Генерація індексу — Створення індексу бази знань
 
 **Результат**:
 ```
@@ -116,18 +190,18 @@ speccrew-workspace/knowledges/techs/{platform-id}/
 └── INDEX.md               # Файл індексу
 ```
 
-### 3.2 Ініціалізація Бізнес-Бази Знань
+### 6.2 Ініціалізація бізнес-бази знань
 
-**Приклад Діалогу**:
+**Приклад розмови**:
 ```
 @speccrew-team-leader ініціалізувати бізнес-базу знань
 ```
 
-**Чотириетапний Процес**:
-1. Інвентаризація Функцій — Сканування коду для ідентифікації всіх функцій
-2. Аналіз Функцій — Аналіз бізнес-логіки кожної функції
-3. Підсумок Модуля — Підсумовування функцій за модулями
-4. Підсумок Системи — Створення бізнес-огляду на рівні системи
+**Чотирьохфазний процес**:
+1. Інвентаризація функцій — Сканування коду для ідентифікації всіх функцій
+2. Аналіз функцій — Аналіз бізнес-логіки для кожної функції
+3. Зведення по модулю — Зведення функцій по модулю
+4. Системне зведення — Генерація бізнес-огляду на рівні системи
 
 **Результат**:
 ```
@@ -140,76 +214,76 @@ speccrew-workspace/knowledges/bizs/
 
 ---
 
-## 4. Посібник Діалогу Етап за Етапом
+## 7. Покроковий посібник по розмові
 
-### 4.1 Етап 1: Аналіз Вимог (Product Manager)
+### 7.1 Фаза 1: Аналіз вимог (Product Manager)
 
-**Як Почати**:
+**Як почати**:
 ```
-@speccrew-product-manager у мене нова вимога: [опишіть вашу вимогу]
+@speccrew-product-manager У мене нова вимога: [опишіть вашу вимогу]
 ```
 
-**Робочий Процес Агента**:
-1. Читання огляду системи для розуміння існуючих модулів
-2. Аналіз вимог користувача
-3. Генерація структурованого документа PRD
+**Робочий процес Agent**:
+1. Прочитати огляд системи для розуміння існуючих модулів
+2. Аналізувати вимоги користувача
+3. Згенерувати структурований документ PRD
 
 **Результат**:
 ```
 iterations/{номер}-{тип}-{ім'я}/01.product-requirement/
-├── [feature-name]-prd.md           # Документ Вимог Продукту
+├── [feature-name]-prd.md           # Документ вимог продукту
 └── [feature-name]-bizs-modeling.md # Бізнес-моделювання (для складних вимог)
 ```
 
-**Контрольний Список Підтвердження**:
-- [ ] Чи опис вимоги точно відображає намір користувача?
-- [ ] Чи бізнес-правила повні?
-- [ ] Чи точки інтеграції з існуючими системами зрозумілі?
-- [ ] Чи критерії прийнятності вимірювані?
+**Контрольний список підтвердження**:
+- [ ] Опис вимоги точно відображає намір користувача?
+- [ ] Бізнес-правила повні?
+- [ ] Точки інтеграції з існуючими системами ясні?
+- [ ] Критерії прийнятності вимірювані?
 
 ---
 
-### 4.2 Етап 2: Проектування Функцій (Feature Designer)
+### 7.2 Фаза 2: Feature Design (Feature Designer)
 
-**Як Почати**:
+**Як почати**:
 ```
-@speccrew-feature-designer розпочати проектування функцій
+@speccrew-feature-designer почати feature design
 ```
 
-**Робочий Процес Агента**:
-1. Автоматичне виявлення підтвердженого документа PRD
-2. Завантаження бізнес-бази знань
-3. Генерація проектування функцій (включаючи UI wireframes, потоки взаємодії, визначення даних, API контракти)
+**Робочий процес Agent**:
+1. Автоматично знайти підтверджений документ PRD
+2. Завантажити бізнес-базу знань
+3. Згенерувати feature design (включаючи UI wireframes, потоки взаємодії, визначення даних, API контракти)
 4. Для кількох PRD використовувати Task Worker для паралельного проектування
 
 **Результат**:
 ```
 iterations/{iter}/02.feature-design/
-└── [feature-name]-feature-spec.md  # Документ проектування функцій
+└── [feature-name]-feature-spec.md  # Документ feature design
 ```
 
-**Контрольний Список Підтвердження**:
-- [ ] Чи всі користувацькі сценарії покриті?
-- [ ] Чи потоки взаємодії зрозумілі?
-- [ ] Чи визначення полів даних повні?
-- [ ] Чи обробка винятків всебічна?
+**Контрольний список підтвердження**:
+- [ ] Всі користувацькі сценарії покриті?
+- [ ] Потоки взаємодії ясні?
+- [ ] Визначення полів даних повні?
+- [ ] Обробка винятків комплексна?
 
 ---
 
-### 4.3 Етап 3: Проектування Системи (System Designer)
+### 7.3 Фаза 3: System Design (System Designer)
 
-**Як Почати**:
+**Як почати**:
 ```
-@speccrew-system-designer розпочати проектування системи
+@speccrew-system-designer почати system design
 ```
 
-**Робочий Процес Агента**:
-1. Виявлення Feature Spec та API Contract
-2. Завантаження технічної бази знань (технологічний стек, архітектура, специфікації для кожної платформи)
-3. **Контрольна Точка A**: Оцінка Фреймворку — Аналіз технічних прогалин, рекомендація нових фреймворків (якщо потрібно), очікування підтвердження користувача
-4. Генерація DESIGN-OVERVIEW.md
-5. Використання Task Worker для паралельної розсилки проектування для кожної платформи (frontend/backend/мобільний/настільний)
-6. **Контрольна Точка B**: Спільне Підтвердження — Показ підсумку всіх дизайнів платформ, очікування підтвердження користувача
+**Робочий процес Agent**:
+1. Знайти Feature Spec та API Contract
+2. Завантажити технічну базу знань (технологічний стек, архітектура, специфікації для кожної платформи)
+3. **Checkpoint A**: Оцінка framework — Аналіз технічних прогалин, рекомендація нових frameworks (якщо необхідно), очікування підтвердження користувача
+4. Згенерувати DESIGN-OVERVIEW.md
+5. Використовувати Task Worker для паралельного розподілу проектування для кожної платформи (frontend/backend/mobile/desktop)
+6. **Checkpoint B**: Спільне підтвердження — Показати зведення всіх дизайнів платформ, очікування підтвердження користувача
 
 **Результат**:
 ```
@@ -217,83 +291,83 @@ iterations/{iter}/03.system-design/
 ├── DESIGN-OVERVIEW.md              # Огляд дизайну
 ├── {platform-id}/
 │   ├── INDEX.md                    # Індекс дизайну платформи
-│   └── {module}-design.md          # Проектування модуля на рівні псевдокоду
+│   └── {module}-design.md          # Проектування модуля рівня pseudocode
 ```
 
-**Контрольний Список Підтвердження**:
-- [ ] Чи псевдокод використовує реальний синтаксис фреймворку?
-- [ ] Чи крос-платформенні API контракти узгоджені?
-- [ ] Чи стратегія обробки помилок уніфікована?
+**Контрольний список підтвердження**:
+- [ ] Pseudocode використовує фактичний синтаксис framework?
+- [ ] Крос-платформні API контракти узгоджені?
+- [ ] Стратегія обробки помилок єдина?
 
 ---
 
-### 4.4 Етап 4: Реалізація Розробки (System Developer)
+### 7.4 Фаза 4: Розробка (System Developer)
 
-**Як Почати**:
+**Як почати**:
 ```
-@speccrew-system-developer розпочати розробку
+@speccrew-system-developer почати розробку
 ```
 
-**Робочий Процес Агента**:
-1. Читання документів проектування системи
-2. Завантаження технічних знань для кожної платформи
-3. **Контрольна Точка A**: Попередня Перевірка Середовища — Перевірка версій runtime, залежностей, доступності сервісів; при невдачі очікування рішення користувача
-4. Використання Task Worker для паралельної розсилки розробки для кожної платформи
-5. Перевірка інтеграції: Узгодження API контрактів, узгодженість даних
-6. Виведення звіту про доставку
+**Робочий процес Agent**:
+1. Прочитати документи системного дизайну
+2. Завантажити технічні знання для кожної платформи
+3. **Checkpoint A**: Попередня перевірка середовища — Перевірити версії runtime, залежності, доступність сервісів; очікувати рішення користувача при збої
+4. Використовувати Task Worker для паралельного розподілу розробки для кожної платформи
+5. Перевірка інтеграції: вирівнювання API контрактів, узгодженість даних
+6. Сформувати звіт про поставку
 
 **Результат**:
 ```
-# Вихідний код записаний у фактичний каталог вихідного коду проекту
+# Вихідний код записується в фактичний каталог вихідного коду проекту
 iterations/{iter}/04.development/
 ├── {platform-id}/
 │   └── tasks/                      # Записи задач розробки
 └── delivery-report.md
 ```
 
-**Контрольний Список Підтвердження**:
-- [ ] Чи середовище готове?
-- [ ] Чи проблеми інтеграції в прийнятних межах?
-- [ ] Чи код відповідає специфікаціям розробки?
+**Контрольний список підтвердження**:
+- [ ] Середовище готове?
+- [ ] Проблеми інтеграції в прийнятному діапазоні?
+- [ ] Код відповідає специфікаціям розробки?
 
 ---
 
-### 4.5 Етап 5: Тестування Системи (Test Manager)
+### 7.5 Фаза 5: Системне тестування (Test Manager)
 
-**Як Почати**:
+**Як почати**:
 ```
-@speccrew-test-manager розпочати тестування
+@speccrew-test-manager почати тестування
 ```
 
-**Триетапний Процес Тестування**:
+**Трьофазний процес тестування**:
 
-| Етап | Опис | Контрольна Точка |
-|------|------|-------------------|
-| Проектування Тест-Кейсів | Генерація тест-кейсів на основі PRD та Feature Spec | A: Показати статистику покриття кейсів та матрицю трасування, очікування підтвердження користувачем достатнього покриття |
-| Генерація Тестового Коду | Генерація виконуваного тестового коду | B: Показати згенеровані тестові файли та мапінг кейсів, очікування підтвердження користувача |
-| Виконання Тесту та Звіт про Баги | Автоматичне виконання тестів та генерація звітів | Немає (автоматичне виконання) |
+| Фаза | Опис | Checkpoint |
+|-------|-------------|------------|
+| Проектування тестових випадків | Генерація тестових випадків на основі PRD та Feature Spec | A: Показати статистику покриття випадків та матрицю трасування, очікування підтвердження користувачем достатнього покриття |
+| Генерація тестового коду | Генерація виконуваного тестового коду | B: Показати згенеровані тестові файли та відображення випадків, очікування підтвердження користувача |
+| Виконання тестів та звіти про помилки | Автоматичне виконання тестів та генерація звітів | Немає (автоматичне виконання) |
 
 **Результат**:
 ```
 iterations/{iter}/05.system-test/
 ├── cases/
-│   └── {platform-id}/              # Документи тест-кейсів
+│   └── {platform-id}/              # Документи тестових випадків
 ├── code/
 │   └── {platform-id}/              # План тестового коду
 ├── reports/
 │   └── test-report-{date}.md       # Звіт про тестування
 └── bugs/
-    └── BUG-{id}-{title}.md         # Звіти про баги (один файл на баг)
+    └── BUG-{id}-{title}.md         # Звіти про помилки (один файл на помилку)
 ```
 
-**Контрольний Список Підтвердження**:
-- [ ] Чи покриття кейсів повне?
-- [ ] Чи тестовий код виконуваний?
-- [ ] Чи оцінка серйозності багів точна?
+**Контрольний список підтвердження**:
+- [ ] Покриття випадків повне?
+- [ ] Тестовий код виконуваний?
+- [ ] Оцінка серйозності помилок точна?
 
 ---
 
-### 4.6 Етап 6: Архівування
+### 7.6 Фаза 6: Архівування
 
 Ітерації автоматично архівуються після завершення:
 
@@ -309,13 +383,13 @@ speccrew-workspace/iteration-archives/
 
 ---
 
-## 5. Огляд Бази Знань
+## 8. Огляд бази знань
 
-### 5.1 Бізнес-База Знань (bizs)
+### 8.1 Бізнес-база знань (bizs)
 
-**Мета**: Зберігання описів бізнес-функцій проекту, поділів модулів, характеристик API
+**Призначення**: Зберігання описів бізнес-функцій проекту, поділу на модулі, характеристик API
 
-**Структура Каталогів**:
+**Структура каталогів**:
 ```
 knowledges/bizs/
 ├── {platform-type}/
@@ -324,13 +398,13 @@ knowledges/bizs/
 └── system-overview.md
 ```
 
-**Сценарії Використання**: Product Manager, Feature Designer
+**Сценарії використання**: Product Manager, Feature Designer
 
-### 5.2 Технічна База Знань (techs)
+### 8.2 Технічна база знань (techs)
 
-**Мета**: Зберігання технологічного стеку проекту, архітектурних угод, специфікацій розробки, специфікацій тестування
+**Призначення**: Зберігання технологічного стеку проекту, архітектурних угод, специфікацій розробки, специфікацій тестування
 
-**Структура Каталогів**:
+**Структура каталогів**:
 ```
 knowledges/techs/{platform-id}/
 ├── tech-stack.md
@@ -340,54 +414,54 @@ knowledges/techs/{platform-id}/
 └── INDEX.md
 ```
 
-**Сценарії Використання**: System Designer, System Developer, Test Manager
+**Сценарії використання**: System Designer, System Developer, Test Manager
 
 ---
 
-## 6. Управління Прогресом Робочого Процесу
+## 9. Управління прогресом робочого процесу
 
-Віртуальна команда SpecCrew дотримується суворого механізму поетапних воріт, де кожен етап повинен бути підтверджений користувачем перед переходом до наступного. Вона також підтримує відновлюване виконання — при перезапуску після переривання автоматично продовжує з того місця, де зупинилася.
+Віртуальна команда SpecCrew дотримується строгого механізму stage-gating, де кожна фаза має бути підтверджена користувачем перед переходом до наступної. Також підтримується відновлюване виконання — при перезапуску після перерви автоматично продовжується з місця зупинки.
 
-### 6.1 Трирівневі Файли Прогресу
+### 9.1 Трирівневі файли прогресу
 
 Робочий процес автоматично підтримує три типи JSON файлів прогресу, розташованих в каталозі ітерації:
 
 | Файл | Розташування | Призначення |
-|------|--------------|-------------|
-| `WORKFLOW-PROGRESS.json` | `iterations/{iter}/` | Записує статус кожного етапу конвеєра |
-| `.checkpoints.json` | Під кожним каталогом етапу | Записує статус підтвердження контрольної точки користувачем |
-| `DISPATCH-PROGRESS.json` | Під кожним каталогом етапу | Записує поелементний прогрес для паралельних задач (багатоплатформні/багатомодульні) |
+|------|----------|---------|
+| `WORKFLOW-PROGRESS.json` | `iterations/{iter}/` | Записує статус кожної фази pipeline |
+| `.checkpoints.json` | Під кожним каталогом фази | Записує статус підтвердження checkpoint користувача |
+| `DISPATCH-PROGRESS.json` | Під кожним каталогом фази | Записує покроковий прогрес для паралельних задач (multi-platform/multi-module) |
 
-### 6.2 Потік Статусу Етапу
+### 9.2 Потік статусу фази
 
-Кожен етап дотримується цього потоку статусу:
+Кожна фаза слідує цьому потоку статусу:
 
 ```
 pending → in_progress → completed → confirmed
 ```
 
 - **pending**: Ще не розпочато
-- **in_progress**: Наразі виконується
-- **completed**: Виконання Агента завершено, очікує підтвердження користувача
-- **confirmed**: Користувач підтвердив через фінальну контрольну точку, наступний етап може розпочатися
+- **in_progress**: Виконується
+- **completed**: Виконання агента завершено, очікування підтвердження користувача
+- **confirmed**: Користувач підтвердив через фінальний checkpoint, наступна фаза може початися
 
-### 6.3 Відновлюване Виконання
+### 9.3 Відновлюване виконання
 
-При перезапуску Агента для етапу:
+При перезапуску Agent для фази:
 
-1. **Автоматична перевірка вище за течією**: Перевіряє, чи підтверджено попередній етап, блокує та нагадує, якщо ні
-2. **Відновлення контрольної точки**: Читає `.checkpoints.json`, пропускає пройдені контрольні точки, продовжує з останньої точки переривання
-3. **Відновлення паралельних задач**: Читає `DISPATCH-PROGRESS.json`, повторно виконує лише задачі зі статусом `pending` або `failed`, пропускає `completed` задачі
+1. **Автоматична перевірка upstream**: Перевіряє, чи підтверджена попередня фаза, блокує та запитує, якщо ні
+2. **Відновлення Checkpoint**: Читає `.checkpoints.json`, пропускає пройдені checkpoints, продовжує з останньої точки перерви
+3. **Відновлення паралельних задач**: Читає `DISPATCH-PROGRESS.json`, повторно виконує тільки задачі зі статусом `pending` або `failed`, пропускає задачі `completed`
 
-### 6.4 Перегляд Поточного Прогресу
+### 9.4 Перегляд поточного прогресу
 
-Перегляд панорамного статусу конвеєра через Агента Лідера Команди:
+Перегляд статусу panorama pipeline через Agent Team Leader:
 
 ```
-@speccrew-team-leader перегляд прогресу поточної ітерації
+@speccrew-team-leader переглянути поточний прогрес ітерації
 ```
 
-Лідер Команди прочитає файли прогресу і відобразить огляд статусу, подібний до:
+Team Leader прочитає файли прогресу і покаже огляд статусу, подібний до:
 
 ```
 Pipeline Status: i001-user-management
@@ -398,25 +472,25 @@ Pipeline Status: i001-user-management
   05 System Test:    ⏳ Pending
 ```
 
-### 6.5 Зворотна Сумісність
+### 9.5 Зворотна сумісність
 
-Механізм файлів прогресу повністю зворотно сумісний — якщо файли прогресу не існують (наприклад, в старих проектах або нових ітераціях), всі Агенти виконуватимуться нормально згідно з оригінальною логікою.
+Механізм файлів прогресу повністю зворотно сумісний — якщо файли прогресу не існують (наприклад, в legacy проектах або нових ітераціях), всі Agents будуть виконуватися нормально згідно оригінальній логіці.
 
 ---
 
-## 7. Часті Запитання (FAQ)
+## 10. Часті запитання (FAQ)
 
-### П1: Що робити, якщо Агент не працює як очікується?
+### П1: Що робити, якщо Agent не працює як очікувалося?
 
-1. Виконайте `speccrew doctor` для перевірки цілісності встановлення
-2. Підтвердьте, що база знань ініціалізована
-3. Підтвердьте, що результат попереднього етапу існує в поточному каталозі ітерації
+1. Виконати `speccrew doctor` для перевірки цілісності встановлення
+2. Підтвердити, що база знань ініціалізована
+3. Підтвердити, що результат попередньої фази існує в поточному каталозі ітерації
 
-### П2: Як пропустити етап?
+### П2: Як пропустити фазу?
 
-**Не рекомендується** — Результат кожного етапу є вхідними даними для наступного етапу.
+**Не рекомендується** — Вихід кожної фази є входом для наступної фази.
 
-Якщо потрібно пропустити, підготуйте вручну вхідний документ відповідного етапу та переконайтеся, що він відповідає специфікаціям формату.
+Якщо необхідно пропустити, вручну підготуйте вхідний документ відповідної фази і переконайтеся, що він відповідає специфікаціям формату.
 
 ### П3: Як обробляти кілька паралельних вимог?
 
@@ -432,87 +506,92 @@ iterations/
 
 ### П4: Як оновити версію SpecCrew?
 
-Оновлення вимагає два етапи:
+Оновлення вимагає двох кроків:
 
 ```bash
-# Етап 1: Оновити глобальний CLI-інструмент
+# Крок 1: Оновити глобальний інструмент CLI
 npm install -g speccrew@latest
 
-# Етап 2: Синхронізувати Агентів та Навички в директорії проекту
+# Крок 2: Синхронізувати Agents та Skills в каталозі проекту
 cd /path/to/your-project
 speccrew update
 ```
 
-- `npm install -g speccrew@latest`: Оновлює сам CLI-інструмент (нові версії можуть включати нові визначення Агентів/Навичок, виправлення помилок тощо)
-- `speccrew update`: Синхронізує файли визначень Агентів та Навичок у вашому проекті до останньої версії
+- `npm install -g speccrew@latest`: Оновлює сам інструмент CLI (нові версії можуть включати нові визначення Agent/Skill, виправлення помилок тощо)
+- `speccrew update`: Синхронізує файли визначення Agent та Skill в вашому проекті до останньої версії
 - `speccrew update --ide cursor`: Оновлює конфігурацію тільки для конкретної IDE
 
-> **Примітка**: Обидва етапи обов'язкові. Виконання тільки `speccrew update` не оновить сам CLI-інструмент; виконання тільки `npm install` не оновить файли проекту.
+> **Примітка**: Обидва кроки вимагаються. Виконання тільки `speccrew update` не оновить сам інструмент CLI; виконання тільки `npm install` не оновить файли проекту.
+
+### П5: `speccrew update` показує доступну нову версію, але `npm install -g speccrew@latest` все ще встановлює стару версію?
 
-### П5: `speccrew update` показує нову версію, але після встановлення все ще стара?
+Це зазвичай викликано кешем npm. Рішення:
 
-Зазвичай це викликано кешем npm. Рішення:
 ```bash
+# Очистити кеш npm та перевстановити
 npm cache clean --force
 npm install -g speccrew@latest
+
+# Перевірити версію
 npm list -g speccrew
 ```
-Якщо все ще не працює, встановіть конкретну версію:
+
+Якщо все ще не працює, спробуйте встановити з конкретним номером версії:
 ```bash
 npm install -g speccrew@0.5.6
 ```
 
 ### П6: Як переглянути історичні ітерації?
 
-Після архівування перегляньте в `speccrew-workspace/iteration-archives/`, організовано у форматі `{номер}-{тип}-{ім'я}-{дата}/`.
+Після архівування переглянути в `speccrew-workspace/iteration-archives/`, організовано за форматом `{номер}-{тип}-{ім'я}-{дата}/`.
 
-### П7: Чи база знань потребує регулярного оновлення?
+### П7: Чи потрібне регулярне оновлення бази знань?
 
-Реініціалізація потрібна в наступних ситуаціях:
-- Значні зміни структури проекту
+Повторна ініціалізація вимагається в наступних ситуаціях:
+- Значні зміни в структурі проекту
 - Оновлення або заміна технологічного стеку
 - Додавання/видалення бізнес-модулів
 
 ---
 
-## 8. Швидка Довідка
+## 11. Коротка довідка
 
-### Швидка Довідка Запуску Агентів
+### Коротка довідка по запуску Agents
 
-| Етап | Агент | Початковий Діалог |
-|------|-------|-------------------|
+| Фаза | Agent | Початкова розмова |
+|-------|-------|-------------------|
 | Ініціалізація | Team Leader | `@speccrew-team-leader ініціалізувати технічну базу знань` |
-| Аналіз Вимог | Product Manager | `@speccrew-product-manager у мене нова вимога: [опис]` |
-| Проектування Функцій | Feature Designer | `@speccrew-feature-designer розпочати проектування функцій` |
-| Проектування Системи | System Designer | `@speccrew-system-designer розпочати проектування системи` |
-| Розробка | System Developer | `@speccrew-system-developer розпочати розробку` |
-| Тестування Системи | Test Manager | `@speccrew-test-manager розпочати тестування` |
-
-### Контрольний Список Контрольних Точок
-
-| Етап | Кількість Контрольних Точок | Ключові Елементи Перевірки |
-|------|-----------------------------|---------------------------|
-| Аналіз Вимог | 1 | Точність вимог, повнота бізнес-правил, вимірюваність критеріїв прийнятності |
-| Проектування Функцій | 1 | Покриття сценаріїв, ясність взаємодії, повнота даних, обробка винятків |
-| Проектування Системи | 2 | A: Оцінка фреймворку; B: Синтаксис псевдокоду, крос-платформенна узгодженість, обробка помилок |
+| Аналіз вимог | Product Manager | `@speccrew-product-manager У мене нова вимога: [опис]` |
+| Feature Design | Feature Designer | `@speccrew-feature-designer почати feature design` |
+| System Design | System Designer | `@speccrew-system-designer почати system design` |
+| Розробка | System Developer | `@speccrew-system-developer почати розробку` |
+| Системне тестування | Test Manager | `@speccrew-test-manager почати тестування` |
+
+### Контрольний список Checkpoint
+
+| Фаза | Кількість Checkpoint | Ключові елементи перевірки |
+|-------|----------------------|-----------------|
+| Аналіз вимог | 1 | Точність вимог, повнота бізнес-правил, вимірюваність критеріїв прийнятності |
+| Feature Design | 1 | Покриття сценаріїв, ясність взаємодії, повнота даних, обробка винятків |
+| System Design | 2 | A: Оцінка framework; B: Синтаксис pseudocode, крос-платформна узгодженість, обробка помилок |
 | Розробка | 1 | A: Готовність середовища, проблеми інтеграції, специфікації коду |
-| Тестування Системи | 2 | A: Покриття кейсів; B: Виконуваність тестового коду |
+| Системне тестування | 2 | A: Покриття випадків; B: Виконуваність тестового коду |
 
-### Швидка Довідка Шляхів Результатів
+### Коротка довідка по шляхам результатів
 
-| Етап | Вихідний Каталог | Формат Файлу |
-|------|------------------|-------------|
-| Аналіз Вимог | `iterations/{iter}/01.product-requirement/` | `[name]-prd.md`, `[name]-bizs-modeling.md` |
-| Проектування Функцій | `iterations/{iter}/02.feature-design/` | `[name]-feature-spec.md` |
-| Проектування Системи | `iterations/{iter}/03.system-design/` | `DESIGN-OVERVIEW.md`, `{platform}/INDEX.md`, `{platform}/{module}-design.md` |
+| Фаза | Вихідний каталог | Формат файлу |
+|-------|-----------------|-------------|
+| Аналіз вимог | `iterations/{iter}/01.product-requirement/` | `[name]-prd.md`, `[name]-bizs-modeling.md` |
+| Feature Design | `iterations/{iter}/02.feature-design/` | `[name]-feature-spec.md` |
+| System Design | `iterations/{iter}/03.system-design/` | `DESIGN-OVERVIEW.md`, `{platform}/INDEX.md`, `{platform}/{module}-design.md` |
 | Розробка | `iterations/{iter}/04.development/` | Вихідний код + `delivery-report.md` |
-| Тестування Системи | `iterations/{iter}/05.system-test/` | `cases/`, `code/`, `reports/`, `bugs/` |
-| Архівування | `iteration-archives/{iter}-{дата}/` | Повна копія ітерації |
+| Системне тестування | `iterations/{iter}/05.system-test/` | `cases/`, `code/`, `reports/`, `bugs/` |
+| Архівування | `iteration-archives/{iter}-{date}/` | Повна копія ітерації |
 
 ---
 
-## Наступні Кроки
+## Наступні кроки
 
 1. Виконайте `speccrew init --ide qoder` для ініціалізації вашого проекту
-2. Виконайте Нульовий Крок: Ініціалізація Бази Знань
-3. Просувайтесь через кожен етап слідуючи робочому процесу, насолоджуйтесь досвідом розробки на основі специфікацій!
+2. Виконайте Крок Нуль: Ініціалізація бази знань
+3. Просувайтеся фаза за фазою згідно робочому процесу, насолоджуйтесь досвідом розробки на основі специфікацій!