Проєкт 08. Намалюйте ваш робочий процес як граф

Пов'язана лекція: L14. Від одиночних циклів до графової інженерії

Що ви робитимете

Це проєкт, який переводить вас від «Loop» до «Graph». У попередній лекції ви зібрали maker-checker loop — реалізація, верифікація, зворотний зв'язок, знову реалізація — і всі рішення відбуваються в контекстному вікні одного й того самого агента. У цій лекції ви зробите те, що приховано всередині циклу, видимим та явним: вузли, ребра, спільний стан, правила маршрутизації — випишите все слово за словом.

Ви виконаєте три експерименти, що нарощують складність: спершу намалюєте maker-checker loop з P07 як явний граф, потім додасте до графа паралельний вузол fan-out/fan-in, а вкінці — умовне ребро відкату та вузол ручного затвердження. Коли закінчите, ви на власному досвіді відчуєте одне: граф не новий винахід — це те, чим стає ваш loop, коли ускладнюється до певної міри.

Які інструменти використовувати

• Claude Code або Codex
• Git
• Ваш maker-checker loop із P07 (або будь-який агентний робочий процес, який ви можете ганяти знову і знову)
• Текстовий редактор або інструмент для малювання (малюй не для краси, а щоб прописати структуру; підійде mermaid або написаний вручну graph.md)

Конкретні кроки

Підготовка

1. Почніть із репозиторію після завершення P07 або просто з будь-якого агентного робочого процесу, який ви зараз використовуєте.
2. Створіть три гілки: p08-explicit-graph, p08-parallel, p08-human-in-the-loop.
3. Підготуйте state.md як файл спільного стану: сюди записуються вимоги, прогрес, результати верифікації. Це «спільний робочий стіл» графа.

Експеримент 1: намалюйте Loop як явний граф

Перемкніться на гілку p08-explicit-graph.

1. Перелічіть усі вузли: запишіть кожен крок maker-checker loop з P07 як вузол. Для кожного вузла запишіть: його відповідальність, його вхід, його вихід, чи це агент, чи детермінований код.
2. Намалюйте всі ребра: перелічіть кожне ребро між вузлами. Особливо позначте два особливі ребра:
   • умовне ребро: верифікація пройшла/провалилася — куди йти
   • ребро відкату: при невдачі повернутися до якого вузла
3. Запишіть спільний стан: явно перелічіть, які поля є у стані (вимоги, код, результати тестів, висновок рев'ю), хто їх читає і хто пише.
4. Запишіть правила маршрутизації: найпростішою мовою if-then опишіть «куди йти далі», наприклад:

   if верифікація пройшла → вузол злиття
   if верифікація провалилася → вузол реалізації
   if у вузла реалізації брак інформації → вузол дослідження

5. Оформіть у graph.md: зберіть усе вище у документ. Намалюйте граф у mermaid, докладіть таблицю вузлів і правила маршрутизації.
6. Дай відповідь на питання: після малювання знайдіть принаймні одне раніше неявне ребро — шлях рішення, який раніше був прихований у контексті агента, і ви самі не знали, що він існує.

Експеримент 2: додайте паралельний вузол Fan-out / Fan-in

Перемкніться на гілку p08-parallel.

1. Виберіть точку, яку можна паралелити: знайдіть у завданні місце, яке можна розбити на дві незалежні частини. Наприклад:
   • реалізацію розбити на два незалежні модулі, два агенти пишуть паралельно
   • верифікацію розбити на два незалежні рев'ю: одне запускає тести та lint, інше робить код-рев'ю (різні інструкції, різні фокуси уваги)
   • дослідження розбити на два напрямки, два агенти досліджують кожен свою гілку
2. Запишіть правило fan-out: у спільному стані зафіксуйте, що «це завдання розбито на N паралельних підзавдань», кожне підзавдання — окремий контекст, окремий вузол.
3. Запишіть правило fan-in: коли всі підзавдання завершені, хто зливає результати? Який критерій злиття (наприклад: зливати лише якщо обидва рев'ю пройшли, чи достатньо одного)?
4. Ізолюйте через worktree: кожне паралельне підзавдання працює в окремому git worktree, щоб фізично уникнути колізій файлів (згадайте примітив Worktree з тринадцятої лекції).
5. Запустіть один раз і запишіть: зафіксуйте wall-clock час до/після паралелізації, витрату токенів, якість результату. Паралелізм справді швидший? Чи координаційні накладні витрати з'їли зекономлений час?

Експеримент 3: додайте ребро відкату та вузол ручного затвердження

Перемкніться на гілку p08-human-in-the-loop.

Це найважливіший із трьох експериментів. Ви додасте до графа два види вузлів:

1. Умовне ребро відкату: додайте вузлу верифікації шлях «частково пройшло» — не повертати все цілком у вузол реалізації, а з конкретним зворотним зв'язком повернутися до того вузла, де виникла проблема. Наприклад: тести пройшли, але код-рев'ю виявило, що вимоги зрозуміли неправильно — повертаємося у вузол дослідження, а не у вузол реалізації. Це вимагає, щоб ваш спільний стан фіксував «на якому рівні виникла проблема».
2. Вузол ручного затвердження (Human-in-the-loop): перед вузлом злиття додайте людський вузол. Дійшовши сюди, граф зупиняється і чекає, поки ви напишете в state.md «затвердити» або «відхилити». У вузла затвердження може бути правило таймауту: якщо за N годин немає відповіді — автоматично відхилити або автоматично підняти рівень.
3. Запишіть формат interrupt: як зрозуміло оформити запит на затвердження — що сталося, що змінилося, навіщо потрібна людина, які наслідки затвердження/відхилення.
4. Прокрутіть щонайменше 2 повні цикли: у кожному доходите до вузла ручного затвердження і один раз самі затверджуєте, один раз відхиляєте. Запишіть: чи збігається ваше рішення про затвердження з висновком вузла верифікації? Чи перехоплював вузол затвердження щось, чого вузол верифікації не перехопив?

Як виміряти результат

Показник	Експеримент 1 (явний граф)	Експеримент 2 (паралель)	Експеримент 3 (людина в циклі)
Видимість структури	Скільки неявних ребер ви знайшли?	Чи витримує спільний стан паралельні підзавдання?	Чи може ребро відкату точно локалізувати рівень проблеми?
Локалізація невдачі	При невдачі ви можете вказати, яке ребро помилкове?	Коли паралельне підзавдання впало, ви можете локалізувати, яке саме?	При відхиленні затвердження ви можете вказати, на якому рівні проблема?
Координаційні накладні	Скільки часу пішло на малювання графа?	Зекономлений паралелізмом час vs. координаційні накладні	Час очікування затвердження vs. цінність перехопленої проблеми
Спостережуваність	Що відбувається на кожному кроці — тепер це видно?	Стан кожного паралельного підзавдання видимий?	Чи досить зрозуміло оформлений запит на затвердження?
Надійність	Граф-опис і реальне виконання збігаються?	Критерій fan-in злиття надійний?	Чи реально спрацьовують правила таймауту/підняття рівня?

Що здати

• graph.md (повний опис графа з експерименту 1: mermaid-граф + таблиця вузлів + таблиця ребер + поля спільного стану + правила маршрутизації)
• Перелік неявних ребер, знайдених в експерименті 1 (принаймні одне)
• Правила fan-out/fan-in з експерименту 2 та запис одного паралельного запуску (порівняння часу/вартості/якості)
• Правило ребра відкату з експерименту 3, формат вузла затвердження та запис 2 циклів колаборації «людина в циклі»
• Фінальна рефлексія: що змінилося у вашому способі роботи від loop до графа? Які завдання варті малювання графа, а які — ні?

Пов'язані лекції

• Lecture 14 — Від одиночних циклів до графової інженерії
• Lecture 13 — Від ручного введення промптів до автономних циклів (ваш loop — це один вузол графа; цей проєкт розкладає внутрішню структуру вузла)
• Lecture 09 — Чому агенти оголошують перемогу надто рано (чому вузол верифікації має бути незалежним від вузла реалізації, і в графі це структурне питання)
• Lecture 11 — Чому спостережуваність належить всередині harness (чим складніший граф, тим важливіше бачити, що робить кожен вузол)