Skip to content
← Усі розділи

Розділ 05

Архетипи репозиторіїв

Перш ніж змінити хоча б один рядок коду, агент приймає одне рішення, що визначає все подальше: що це за репозиторій? Архетип, який він виводить, встановлює межу, в рамках якої він розмірковуватиме протягом усього залучення — як він проходить онбординг, як далеко сягає план і де зберігається стан. Помилитися — і агент окреслює роботу для неправильної поверхні, що є найпоширенішим джерелом дрейфу в довгострокових завданнях. Визначити правильно — і він може працювати автономно годинами, адже плани, онбординг і стан відповідають реальній структурі коду.

DWP розрізняє два архетипи. Більшість репозиторіїв належать до першого; другий існує для команд, що координують багато репозиторіїв.

Окремий репозиторій

Типовий випадок: самодостатня кодова база — застосунок, бібліотека чи сервіс. Є єдина цілісна поверхня для розмірковування, тому плани діють безпосередньо на код у репозиторії, а онбординг читає власну структуру й домовленості репозиторію. Агент утримує всю кодову базу як свій контекст і опрацьовує її від початку до кінця.

Ознаки:

  • Єдина цілісна кодова база.
  • Плани змінюють файли в цьому репозиторії.
  • Робочий простір .dwp/ живе в корені репозиторію.

Хаб-оркестратор

Координаційний випадок: репозиторій, чиє завдання — керувати іншими репозиторіями. Тут одиницею роботи є не файл, а дочірній репозиторій, тому плани можуть породжувати дочірні плани в суб-репозиторіях, а онбординг читає реєстр керованих репозиторіїв хабу, а не єдину кодову базу. Агент міркує про межі й передачі — який репозиторій відповідає за яку роботу і як їхній стан залишається узгодженим.

Ознаки:

  • Координує кілька суб-репозиторіїв.
  • Плани можуть делегувати дочірнім планам.
  • Веде реєстр керованих репозиторіїв.
  • Робочий простір .dwp/ у корені хабу відстежує стан між репозиторіями.

Евристика класифікації

Обидва архетипи виглядають по-різному на диску, і агент вибирає між ними за сигналами, які він може перевірити, — а не за ярликом, який йому повідомили. Дерево рішень нижче показує шлях; коротко: вважайте репозиторій хабом-оркестратором лише тоді, коли цього вимагають докази, а в іншому разі — окремим репозиторієм.

Агент має класифікувати репозиторій як хаб-оркестратор, коли знаходить кілька вкладених git-репозиторіїв чи субмодулів, реєстр або маніфест керованих репозиторіїв чи конфігурацію, що вказує на зовнішні репозиторії. За відсутності цих сигналів він вважає репозиторій окремим репозиторієм — безпечне значення за замовчуванням, адже надмірне розширення плану за межі, яких не існує, гірше, ніж робота в межах однієї, яка дійсно існує.

Чим відрізняється онбординг

Архетип — це не косметичний ярлик; він змінює те, що агент читає, що план може зачіпати і де записується стан.

Аспект Окремий Оркестратор
Обсяг Цей репозиторій Кілька репозиторіїв
Онбординг Структура репозиторію Реєстр хабу
Ціль плану Локальні файли Дочірні плани
Стан Локальний .dwp/ Міжрепозиторний .dwp/

Практичний наслідок такий: агент окремого репозиторію міркує про одну кодову базу від початку до кінця, тоді як агент-оркестратор міркує про координацію — який дочірній репозиторій володіє якою роботою і як міжрепозиторний стан лишається узгодженим.

Саме це дає агенту змогу працювати автономно годинами без нагляду: спочатку зафіксувавши архетип, він окреслює плани, онбординг та стан до правильної межі, тож кожне завдання — від першого до останнього — виконується на коректній поверхні.