Atomare Aufgaben (Atomare Aufgabendekomposition)

1. Konzeptüberblick und systemisches Problem

In der klassischen Softwareentwicklung sind vage Aufgabenstellungen („Implementierung der Authentifizierung“, „Refactoring des Suchmoduls“) die Hauptursache für Terminverzögerungen und Nacharbeit. Im Zeitalter der KI-Agenten-gestützten Entwicklung haben sich die Kosten einer schlechten Dekomposition um ein Vielfaches erhöht.

Wenn ein Ingenieur einem Agenten eine hochrangige, unpräzise Anweisung gibt, trifft dieser Annahmen zu Dutzenden von undefinierten Details. Das Ergebnis ist ein monolithischer Diff über 40 Dateien, in dem UI-Layout, Datenbankschemas und Geschäftslogik vermischt sind. Eine Überprüfung eines solchen Diffs ist praktisch unmöglich: Der Ingenieur erlebt kognitive Überlastung, klickt auf „Accept“ und sieht sich eine Woche später mit unlösbaren Konflikten konfrontiert.

Atomic Tasks (Atomare Aufgaben) sind eine ingenieurtechnische Disziplin zur Strukturierung von Arbeit nach dem Prinzip der Unteilbarkeit:

• Jede Teilaufgabe fokussiert sich auf eine einzige Verhaltens- oder Strukturänderung.
• Sie verfügt über klar definierte Eingabeparameter und erwartete Ausgabe-Invarianten.
• Sie kann vollständig implementiert, getestet und committet werden, unabhängig vom Rest des Systems.

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

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

2. Architektonische Taxonomie und mentales Modell

Gradierung der Granularitätsstufen von Aufgaben (Task Granularity Spectrum):

1. Makro-Ebene (System Feature / Epic):
   • Geschäftsziel (z. B. „Unterstützung von Mehrsprachigkeit auf der Website“). Darf nicht als einzelne Befehl direkt im Chat an den Agenten übergeben werden.
2. Atomares Modul (Feature Slice / Component):
   • Vertikaler Funktions-Slice (z. B. „Routing von Locales über Middleware“).
3. Atomare Aktion (Atomic Micro-Task):
   • Konkreter Schritt zur Modifikation einer einzigen Schicht: „Erstellen eines Übersetzungswörterbuchs für die 404-Seite im JSON-Format und Hinzufügen strikter Typisierungen für Schlüsselwörter“.
   • Ausführungszeit: 2–5 Minuten.
   • Anzahl geänderter Zeilen: bis zu 50–100 Zeilen.

3. Technischer Pipeline und interne Mechanik

Vorlage für eine ingenieurtechnische atomare Aufgabe (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 помилок.

Ausführungspipeline für einen atomaren Schritt:

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. Praktische Ingenieurs-Szenarien im Produktionsbetrieb

01. Sichere Datenbankmigration bei 10 Millionen Datensätzen

Anstatt einer komplexen Gesamt-Migration zerlegt das Team die Aufgabe in 4 atomare Tasks: 1) Hinzufügen einer neuen Spalte als nullable; 2) Schreiben eines Hintergrundskripts zur Batch-Synchronisation von je 1000 Datensätzen; 3) Umschalten der Schreibvorgänge auf die neue Spalte; 4) Hinzufügen der Einschränkung NOT NULL und Löschen des alten Feldes. Jeder Schritt wird separat überprüft und deployed, was das Risiko einer Tabellensperre eliminiert.

02. Ausweg aus der kreativen Sackgasse beim Debugging

Ein Ingenieur versteht nicht, warum ein komplexer Routenberechnungs-Algorithmus falsche Ergebnisse liefert. Anstatt fruchtlos eine 1000-Zeilen-Datei zu analysieren, zerlegt er den Algorithmus in 5 reine Unterfunktionen und schreibt für jede einen separaten Test. Bei der 3. Unterfunktion wird ein Rundungsfehler entdeckt, und der Bug ist in 3 Minuten behoben.

03. Paralleles Dirigieren von Subagenten (Parallel Subagents)

Dank der Atomarität kann der Architekt 3 verschiedene Modell-Sessions gleichzeitig starten: Ein Agent schreibt einen XML-Parser, ein zweiter einen PDF-Berichtsgenerator und ein dritter das Datenbankschema. Da ihre Verträge atomar sind und keine gemeinsamen Dateien überschneiden, treten keinerlei Merge Conflicts auf.

5. Fallstricke, typische Fehler und Sicherheit

1. Fragmentierungsparalyse (Micro-Task Hell): Eine übermäßige Dekomposition einer Aufgabe in 50 kleine Schritte à 30 Sekunden erzeugt bürokratische Reibung: Die Zeit für die Formulierung des Prompts und das Warten auf die Antwort beginnt, die Zeit für das eigentliche Coden zu übersteigen. Bewahren Sie einen gesunden Maßstab: Eine atomare Aufgabe sollte einen substanziellen Problemlösungsschritt enthalten.
2. Verlust globaler Invarianten (Local Optimum Trap): Jede atomare Aufgabe kann auf ihrer Ebene perfekt ausgeführt werden, aber im Gesamtkontext können Module inkonsistent sein, wenn der gemeinsame Interface-Contract (Contract-First Design) nicht vorab festgelegt wurde.
3. Anhäufung nicht committeten Mülls: Wenn nach der Ausführung jeder atomaren Aufgabe kein git commit erfolgt, verwandelt sich das Arbeitsverzeichnis nach 5 Iterationen in ein Chaos aus Hunderten unverständlicher Änderungen, und die Vorteile der Atomarität gehen vollständig verloren.