Atomic Tasks (Атомарна декомпозиція задач)(Атомарна декомпозиція задач)

1. Огляд концепції та системна проблема

У класичній розробці розмиті завдання ("Зробити авторизацію", "Переписати модуль пошуку") є головним джерелом затягування строків та переробки. В епоху розробки за участі AI-агентів ціна поганої декомпозиції зросла багаторазово.

Коли інженер дає агенту високорівневу розмиту інструкцію, агент робить припущення щодо десятків невизначених деталей. В результаті генерується монолітний дифф на 40 файлів, де змішано верстку, схеми бази даних та бізнес-правила. Перевірити такий дифф практично неможливо: інженер відчуває когнітивне перевантаження, натискає "Accept", а через тиждень стикається з нерозв'язними конфліктами.

Atomic Tasks (Атомарні задачі) — це інженерна дисципліна структурування роботи за принципом неподільності:

• Кожна підзадача фокусується на одній зміні поведінки або структури.
• Вона має чітко окреслені вхідні параметри та очікувані вихідні інваріанти.
• Вона може бути повністю реалізована, протестована та закоммічена окремо від решти системи.

Хаотичний моноліт (Провал агента):
[Вимога: "Зроби мені інтернет-магазин"] ---> [LLM генерує кашу на 30 файлів із заглушками]

Атомарна декомпозиція (Контрольований успіх):
[Вимога: "Оформлення замовлення"]
   |
   +---> Задача 1: Створити Drizzle-схему таблиці Order + міграція (Перевірка: db:push)
   |
   +---> Задача 2: Написати чисту функцію calculateTotal(items, discount) (Перевірка: 5 unit-тестів)
   |
   +---> Задача 3: Реалізувати POST /api/orders з валідацією Zod (Перевірка: curl / API тест)
   |
   +---> Задача 4: Створити UI-форму оформлення замовлення (Перевірка: компонент у браузері)

2. Архітектурна таксономія та ментальна модель

Градація рівнів гранулярності задач (Task Granularity Spectrum):

1. Макро-рівень (System Feature / Epic):
   • Бізнес-мета (наприклад, "Підтримка мультимовності сайту"). Не підлягає прямому згодовуванню в чат агента як одна команда.
2. Атомарний модуль (Feature Slice / Component):
   • Вертикальний зріз функціоналу (наприклад, "Маршрутизація локалей через middleware").
3. Атомарна дія (Atomic Micro-Task):
   • Конкретний крок з модифікації одного шару: "Створити словник перекладів для сторінки 404 у форматі JSON і додати строгі типи ключових слів".
   • Час виконання: 2–5 хвилин.
   • Кількість змінених рядків: до 50–100 рядків.

3. Технічний пайплайн та внутрішня механіка

Шаблон інженерної атомарної задачі (TASK_SPEC.md)

### Задача: Створення репозиторію для збереження токенів сесії

**Контекст файлів:**
- Цільовий файл: `src/lib/auth/session-store.ts`
- Тестовий файл: `src/lib/auth/__tests__/session-store.test.ts`
- Довідковий контракт: `src/lib/auth/types.ts`

**Вимоги:**
1. Реалізувати клас `RedisSessionStore`, що імплементує інтерфейс `SessionStore`.
2. Метод `saveSession(token, data, ttlSeconds)` повинен встановлювати ключ із TTL за допомогою команди Redis `SETEX`.
3. Метод `getSession(token)` повинен повертати десеріалізований об'єкт або `null`, якщо ключ відсутній.

**Критерій завершення (Definition of Done):**
- Команда `npx vitest run src/lib/auth/__tests__/session-store.test.ts` повертає 100% успішних тестів.
- Відсутні помилки типізації: `npx tsc --noEmit` проходить з 0 помилок.

Пайплайн виконання атомарного кроку:

1. Інженер формулює TASK_SPEC з чітким контекстом і тестом.
2. Агент читає ЛИШЕ вказані 2-3 файли (чисте вікно контексту, нуль галюцинацій).
3. Агент пише реалізацію.
4. Запуск автотесту -> зелене світло.
5. Інженер перевіряє компактний diff (20 рядків) за 15 секунд.
6. Git commit: `git commit -m "feat(auth): implement redis session store"`

4. Практичні інженерні сценарії в продакшені

01. Безпечна міграція бази даних на 10 мільйонів рядків

Замість однієї комплексної міграції команда розбиває задачу на 4 атомарні таски: 1) Додати нову колонку як nullable; 2) Написати фоновий скрипт батч-синхронізації по 1000 рядків; 3) Перемкнути запис у нову колонку; 4) Додати обмеження NOT NULL та видалити старе поле. Кожен етап перевіряється і деплоїться окремо, усуваючи ризик блокування таблиці.

02. Вихід зі стану творчого глухого кута під час дебагу

Інженер не розуміє, чому складний алгоритм розрахунку маршруту повертає невірний результат. Замість безплідного розглядання всього файлу на 1000 рядків, він розбиває алгоритм на 5 чистих підфункцій і пише до кожної окремий тест. На 3-й підфункції виявляється помилка округлення дробів, і баг усувається за 3 хвилини.

03. Паралельний дирижабль субагентів (Parallel Subagents)

Завдяки атомарності архітектор може запустити 3 різні сесії моделі одночасно: один агент пише парсер XML, другий — генератор PDF звітів, третій — схему бази даних. Оскільки їхні контракти атомарні та не перетинаються в спільних файлах, відсутні будь-які конфлікти злиття (Merge Conflicts).

5. Підводні камені, типові помилки та безпека

1. Параліч фрагментації (Micro-Task Hell): Надмірна декомпозиція задачі на 50 дрібних кроків по 30 секунд кожен створює бюрократичне тертя: час на формулювання промпта та очікування відповіді починає перевищувати час написання коду. Зберігайте здоровий масштаб: 1 атомарна задача повинна містити змістовний крок вирішення проблеми.
2. Втрата глобального інваріанту (Local Optimum Trap): Кожна атомарна задача може бути виконана ідеально на своєму рівні, але в комплексі модулі можуть не стикуватися, якщо спочатку не було зафіксовано спільний інтерфейсний контракт (Contract-First Design).
3. Накопичення незакомміченого сміття: Якщо після виконання кожної атомарної задачі не робити git commit, через 5 ітерацій робоче дерево перетворюється на хаос із сотень незрозумілих змін, і переваги атомарності повністю втрачаються.