---

title: SPARC методологія — canonical reference status: active last_updated: 2026-05-10

SPARC методологія

Що це

5-фазний waterfall для будь-якої нової фічі або проекту. Кожна фаза має чіткий артефакт. Наступна фаза не починається без апруву попередньої. Запозичено з ruvnet/ruflo, адаптовано під наш стек (PM-Agent, Dev Crew, wiki, Telegram review).

SPARC → українські назви

Літера	Англ.	Українська	Що це
S	Specification	Специфікація	Що робимо і навіщо. Вимоги, цілі, метрики, edge cases
P	Pseudocode	Псевдокод	Логіка кроків без коду. Flow, структури даних
A	Architecture	Архітектура	Стек, файлова структура, інтерфейси, deploy
R	Refinement	Реалізація	TDD-цикл (тест → код → рефактор)
C	Completion	Завершення	Deploy, smoke-тест, документація, sign-off

S → P → A → R → C
│   │   │   │   └─ Completion (Завершення): deploy + smoke + sign-off
│   │   │   └───── Refinement (Реалізація): TDD-цикл
│   │   └───────── Architecture (Архітектура): стек, файли, інтерфейси
│   └───────────── Pseudocode (Псевдокод): логіка кроків без коду
└───────────────── Specification (Специфікація): вимоги, цілі, метрики

Артефакти і де лежать

/srv/wiki/projects/<area>/<slug>/sparc/
├── 01-specification.md   # S
├── 02-pseudocode.md      # P
├── 03-architecture.md    # A
├── 04-refinement.md      # R (журнал TDD-прогресу)
└── 05-completion.md      # C

Шаблони — в /srv/wiki/_templates/sparc/.

Опис фаз

S — Specification (Специфікація)

Мета: зрозуміти що ми робимо і навіщо. Без коду, без логіки. Артефакт: 01-specification.md — вимоги, цілі, не-цілі, метрики успіху, edge cases, відкриті питання. Sign-off: Сергій схвалює scope перед переходом до P. Типова тривалість: 1-2 дні для нової фічі, 0.5 дня для невеликих задач.

P — Pseudocode (Псевдокод)

Мета: зловити логічні діри і галюцинації ДО коду. Артефакт: 02-pseudocode.md — flow без типів і коду, лише послідовність кроків і структури даних. Sign-off: ревю самим собою (Claude) або тех-leader'ом. Не завжди потрібен Сергій. Типова тривалість: кілька годин.

A — Architecture (Архітектура)

Мета: обрати стек, спроектувати файлову структуру і інтерфейси. Артефакт: 03-architecture.md — таблиця стеку, дерево директорій, ключові інтерфейси, потоки даних, безпека, деплой. Sign-off: Сергій схвалює перед TDD (R) — щоб не переписувати потім. Типова тривалість: 0.5-1 день.

R — Refinement (Реалізація)

Мета: реалізація через TDD. Тест → код → рефактор. Артефакт: 04-refinement.md (журнал) + реальні тести і код у /srv/projects/<slug>/. Sign-off: усі тести green + coverage ≥ target + NFR відповідає specification. Типова тривалість: залежить від scope, основна частина роботи.

C — Completion (Завершення)

Мета: deploy, smoke-тест, документація, фінальне підтвердження. Артефакт: 05-completion.md — checklist деплою, smoke-результати, метрики vs targets. Sign-off: Сергій підтверджує що все працює у проді. Типова тривалість: 0.5 дня.

Режими

Full SPARC (5 фаз)

Стандарт для нового проекту або великої фічі (>1 тиждень роботи).

Quick SPARC (S + R + C)

Для дрібних задач (<2 дні). Пропускаємо P і A — йдемо одразу від specification до TDD-цикла. Завершуємо стандартним C.

Запуск: python3 crew.py --project <name> --quick Або slash: /sparc-spec --quick "task description"

Telegram review gates

За замовчуванням Сергій бачить апрув-запит на:

• S → P (схвалення scope перед розпрацюванням)
• R → C (перед deploy)

Проміжні (P → A, A → R) — авто, без gate. Це налаштовується в PM-Agent v0.4.

Readiness_pct формула

readiness_pct = (completed_phases / 5) * 100

Completed phases	readiness_pct
0 (нічого не починали)	0%
S	20%
S + P	40%
S + P + A	60%
S + P + A + R	80%
S + P + A + R + C	100%

Для quick-режиму (3 фази):

Completed	readiness_pct
0	0%
S	33%
S + R	67%
S + R + C	100%

PM-Agent v0.4 рахує це автоматично з frontmatter sparc_phase.

Migration legacy проектів

Старі проекти не мають sparc/ папки. PM-Agent при першому запуску виконує bootstrap:

1. Читає index.md → витягує goals/requirements у 01-specification.md
2. Frontmatter sparc_phase: bootstrap
3. Сергій ревью'є → переводить у sparc_phase: S
4. Далі звичайний цикл

Якщо проект уже фактично виконаний — bootstrap відразу у sparc_phase: complete, readiness=100%.

Slash-команди (заплановано Etap 4)

• /sparc-spec <project> "<task>" — створює 01-specification.md
• /sparc-pseudocode <project> — генерує 02-pseudocode.md зі spec'у
• /sparc-arch <project> — генерує 03-architecture.md
• /sparc-refine <project> — TDD-цикл (R)
• /sparc-complete <project> — фінальна перевірка
• /sparc-status <project> — показує поточну фазу + блокери

Інтеграція з нашими crews

• Dev Crew v2 — переробляється на pipeline по 5 фазах. Кожна роль закріплена за фазою (див. sparc-upgrade-plan.md).
• Case Builder Crew — лишається як є, не SPARC-fits (доменна задача генерації клінічних кейсів).
• Google Ads Crew, legal-advisor, Scout Agent — не зачіпаємо.

FAQ

Q: SPARC обов'язковий для всіх нових проектів? A: Так, для проектів і великих фіч. Для одноразових задач (баг-фікс на 30 хв) — не оверкіл.

Q: Що якщо я під час R виявив що Architecture неправильна? A: Повертаємось у A, оновлюємо 03-architecture.md, sign-off знову, потім продовжуємо R. Не приховуємо.

Q: Skip окрему фазу можна? A: У quick-режимі — P і A пропускаються. У full-режимі — всі 5 обов'язкові.

Q: Сергію треба апрувати кожен sign-off? A: Тільки S → P і R → C. Решта — авто.