Як працюють AI-агенти

Джерело правди: хто відповідає на яке питання

У попередніх главах ми з’ясували, як працює агент і чому його контекст обмежений. Тепер розгляньмо, як він має знаходити знання про проєкт. У типовій…

Глава 25Заморожене українське видання

У попередніх главах ми з’ясували, як працює агент і чому його контекст обмежений. Тепер розгляньмо, як він має знаходити знання про проєкт. У типовій роботі одночасно існують завдання в Jira, код і документація в Git, обговорення в pull request, дані в базі, схвалені матеріали у Drive, повідомлення в чаті, журнали виконання й коротка пам’ять агента. Вони не обов’язково суперечать одне одному: часто вони відповідають на різні запитання.

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

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

25.1. Чотири різні ролі

Джерело правди (source of truth) — система або конкретний запис, якому команда довірила відповідати на певне питання. Цей статус задається процесом і межами, а не розширенням файла чи назвою продукту. Наприклад, розділ затверджених умов у Drive може бути джерелом для чинної комерційної політики. Папка Drive сама по собі не робить кожен файл у ній схваленим.

Система обліку (system of record) — місце, де ведеться авторитетний набір записів певної категорії: наприклад, облікові записи клієнтів у базі даних або вимоги до функції у Jira. Система обліку може зберігати зміни й дозволяти аудит. Це не означає, що вона є джерелом усіх видів істини. Запис клієнта не визначає, що обіцяно клієнтам; Jira не доводить, що новий код уже обслуговує трафік.

Поточний стан виконання (runtime state) — те, що система фактично робить або зберігає зараз: версія застосунку, яка відповідає на запит; чинна конфігурація; стан конкретного замовлення; живий процес. Це спостереження прив’язане до часу, середовища й методу перевірки. Вчорашній знімок стану не доводить сьогоднішнього.

Журнал подій або змін (event log / change history) — запис про те, що система побачила чи зареєструвала в певному порядку: перехід статусу, запит, помилку, коміт, редагування поля. Він допомагає пояснити, як виник стан. Але подія «користувач натиснув “Опублікувати”» ще не доводить, що сайт успішно розгорнувся; журнал міг бути неповним або дія могла завершитися помилкою.

Зручна копія — витяг, короткий переказ, експорт, локальна копія, кеш, пошуковий індекс, вікі-сторінка або пам’ять агента. Вона прискорює пошук чи читання, але її авторитет залежить від походження, свіжості та способу оновлення. Називати її «копією джерела» недостатньо: потрібні посилання й дата або версія, інакше неможливо перевірити відповідність.

Ці ролі можна зобразити простим потоком:

авторитетний запис → похідне представлення → пошук або підсумок → відповідь

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

25.2. Авторитет залежить від запитання

Запитання	Найкраще місце для першої перевірки	Чого це місце саме по собі не доводить
Який код або текст документа записано в конкретній ревізії?	Git-репозиторій, конкретна гілка та коміт; історія файла показує зміни.	Що цей коміт уже на основній гілці, розгорнутий або працює у виробництві.
Яку потребу та критерії описали для роботи?	Jira: опис, критерії приймання, власник, статус і історія полів.	Що реалізацію змерджено, перевірено або розгорнуто.
Що саме запропоновано й обговорено для коду?	Запит на злиття (pull request): опис, перелік відмінностей (diff), коміти, коментарі, огляди та перевірки.	Що запропоновану зміну змерджено чи що виробництво працює на ній.
Який запис система зберігає для сутності?	Відповідна база або сервіс доменних записів.	Що запис відповідає очікуваній політиці або що користувач бачив саме його.
Який процес чи матеріал офіційно схвалений?	Визначений власником документ у Drive чи корпоративному сховищі, разом зі статусом схвалення та версією.	Що будь-який сусідній документ або його скриншот має той самий статус.
Що люди сказали або уточнювали під час роботи?	Чат чи запис зустрічі з автором і часовою позначкою.	Що репліка була рішенням, схваленням або чинною політикою.
Що агент пам’ятає про проєкт?	Пам’ять агента — лише покажчик до фактів, які треба переперевірити.	Що нотатка повна, актуальна або має повноваження змінювати правило.
Яка версія відповідає зараз?	Живий статус розгортання, метадані артефакту, конфігурація та контрольне спостереження в потрібному середовищі.	Що історія Git або статус Jira автоматично дорівнюють поточному стану.

Питання «що є джерелом правди?» треба уточнити до рівня «правдою про що, для якої області, станом на який час?» Файл README.md («прочитай мене») може бути найкращим коротким описом запуску, але не свідчить про версію живого сервісу. Журнал помилок може надійно показати конкретний збій, але не має права визначити, що продукт повинен робити. Коментар клієнта є доказом повідомлення клієнта, але не обов’язково формальним схваленням зміни ціни.

25.3. Картка запису: автор, версія, межі й походження

Перш ніж покладатися на документ або повідомлення, перевірте його контекст авторитетності. Для важливого запису корисно мати:

Автор або власник змісту. Хто написав текст? Хто відповідає, щоб він залишався правильним?
Дату й чинність. Коли запис створено чи переглянуто? З якої дати він діє? Дата редагування не обов’язково є датою схвалення.
Версію. Коміт, номер редакції, ідентифікатор рішення, номер контракту або інший стабільний покажчик.
Область застосування. Для якого продукту, клієнтів, середовища, країни, команди чи періоду діє правило? Винятки теж мають бути явними.
Статус і схвалення. Це чернетка, пропозиція, затверджена версія, відхилений запис чи застаріла інструкція? Хто і в якій ролі схвалив?
Доступ. Чи може людина або агент читати сам запис, історію, додатки й потрібне середовище? Назва документа в результатах пошуку не означає, що його вміст прочитано.
Походження. Звідки взявся цей витяг або факт? Для похідного документа потрібне посилання на оригінал і вказівка, з якої версії його сформовано.
Наступну дію при зміні. Хто оновлює копії, кого сповіщає або яке завдання створює, коли рішення змінюється?

Часова позначка сама не вирішує суперечку. Учорашній неузгоджений коментар не скасовує затверджене минулого тижня правило. Чернетка з новішою датою не стає політикою. Натомість старий запис може й досі діяти, якщо його ніхто не замінив. Потрібно встановити статус, власника рішення й точну межу чинності.

У Git ідентифікатор коміту дає змогу назвати конкретний знімок файлів. Сторінка GitHub для файла може показати його історію, автора, повідомлення й дату коміту. Pull request об’єднує опис, обговорення, коміти, перевірки та перелік відмінностей між змінами (diff), але це історія пропозиції і рецензування; для відповіді «що в основній гілці?» відкрийте відповідну гілку й коміт. Документація GitHub про перегляд файлів і їхньої історії та про pull request описує ці можливості окремо.

У Jira теж важливо розрізняти поточне поле й історію. Статус «Завершено» відповідає на запитання про записаний статус задачі в робочому процесі. Він може бути помилковим або випереджати код. Історія завдання показує зміни полів, переходи й коментарі, однак не замінює перевірку GitHub чи робочого середовища. Atlassian описує історію роботи саме як записи редагувань і переходів.

25.4. Чому не варто зберігати все в одному місці

Одна система не однаково добре відповідає на всі запити. Jira зручна для власника роботи, черги й статусу. Git — для версій коду та документації. База даних — для оперативних записів із контрольованою структурою. Сховище документів — для матеріалів, які схвалюються й поширюються широкою аудиторією. Чат підходить для швидких уточнень. Журнали — для діагностики того, що система спостерігала. Злиття всіх цих функцій в одну сторінку не прибирає відмінностей; воно може сховати їх за одним великим полотном.

Практична ідея з The E-Myth Revisited Майкла Е. Гербера — не тримати операційну роботу залежною від однієї людини: систему й очікуваний спосіб роботи має бути можливо передати. У книжковій анотації й матеріалах команди EMyth ця думка описана як систематизований спосіб виконання процесів, який інші люди можуть зрозуміти й підтримувати. Для документації це означає: цінне рішення не може існувати тільки «в голові засновника» або в приватній переписці; власник знання має бути готовий оновлювати чинний запис і передавати його наступній людині. Але висновок не такий, що треба задокументувати кожен рух або створити бюрократичний довідник на тисячу сторінок. Документуйте те, що повторюється, впливає на рішення, ризики, клієнтів або передачу відповідальності. Це застосування ідеї Гербера до командного знання, а не твердження, що він пропонував конкретну політику файлів чи розподілених команд.

У другому виданні Designing Data-Intensive Applications (DDIA, Проєктування застосунків із інтенсивною роботою з даними) Мартін Клеппманн і Кріс Ріккоміні розглядають системи обліку та похідні дані, а також причини поєднувати різні сховища, коли одне не покриває всі потреби. Це корисна аналогія для документів: схвалене правило може бути первинним записом, а довідник, пошуковий індекс чи зведення — похідним представленням; якщо похідне зіпсувалося, його можна відбудувати з первинного лише за наявності чіткого зв’язку та правил перетворення. Треба також думати про свіжість копії й історію зміни. Документація не є транзакційною базою даних: вона не гарантує атомарного оновлення всіх копій, автоматичної узгодженості або відтворюваного стану. Порівняння пояснює напрямок даних, але не обіцяє технічної гарантії.

25.5. Копії, витяги та похідні матеріали

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

Виберіть один із трьох простих режимів:

Посилання замість копіювання. У README чи задачі вказати URL на затверджений запис і пояснити, яка його частина важлива.
Автоматично створена копія. Якщо довідник генерується з джерела, зазначити скрипт/процес, джерело, версію й час генерації; редагувати першоджерело, а не вихідний файл.
Ручний витяг. Якщо копія потрібна, позначити її «похідний витяг», послатися на джерело, зафіксувати його версію й дату звірки, назвати власника та встановити подію, після якої витяг треба перевірити.

Наприклад:

Похідний виклад вимог до зберігання клієнтських даних. Джерело: затверджена політика «Data Handling», редакція 4 від 2026-08-12. Власниця джерела — керівниця безпеки. Перевірено 2026-09-15. Звіряти після кожної зміни політики або перед зміною експорту даних. Повний текст правила — за посиланням.

Не підтримуйте два «головні» файли, де різні люди можуть незалежно змінити те саме правило. Якщо це неминуче, треба явно призначити, де вноситься зміна, як вона потрапляє до другої системи, який максимальний лаг прийнятний і хто ловить невдалу синхронізацію.

Відкритий репозиторій MADR (Markdown Architectural Decision Records — записи архітектурних рішень у Markdown) є конкретним прикладом такого підходу для рішень: репозиторій радить зберігати нумеровані записи в папці docs/decisions, використовує окрему папку шаблонів і має журнал змін. Повний шаблон версії 4.0.0 містить контекст, обраний варіант, наслідки та метадані — статус, дату й тих, хто ухвалює рішення. У changelog автори пояснюють, що формулювання “Markdown Any Decision Record” з’являлося у бета-версії, а реліз 4.0.0 повернув початкову назву “Markdown Architectural Decision Records”. Це не універсальний стандарт і не доказ, що кожна команда повинна мати запис архітектурного рішення (ADR, architectural decision record) для кожної дрібниці; це перевірюваний приклад того, як рішення можна версіонувати разом із проєктом.

25.6. Якщо джерела конфліктують

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

Сформулюйте конкретне запитання. «Яке правило діє для цього тарифу в ЄС із 1 жовтня?» краще за «Який документ правильний?».
Зафіксуйте конфлікт без переказу зручними словами. Назвіть уривок, файл чи поле, дату, версію та область кожного джерела.
Перевірте статус і походження. Чернетка чи затверджений документ? З якого запису зроблено копію? Чи йдеться про одну країну й один період?
Знайдіть уповноваженого власника. Це може бути власник продуктового правила, відповідальна за політику або визначена особа, що має право підтвердити зміну. Інструмент або агент не отримує такого права з самого факту доступу.
Не вигадуйте відсутнє рішення. Якщо джерело не дає відповіді, призупиніть дію, яка залежить від цього правила, поставте точне запитання та запропонуйте безпечне тимчасове обмеження, якщо воно потрібне.
Оновіть канонічний запис і залежні місця. Зафіксуйте рішення, обґрунтування, власника, дату чинності й те, що воно замінює. Оновіть або позначте як застарілі README, довідку, задачу, шаблон і індекс. Старий запис не видаляйте, якщо історія потрібна для пояснення попередньої поведінки.
Перевірте поширення. Повторно відкрийте місця-копії й підтвердіть, що вони містять посилання на нову версію або зрозумілий напис «застаріло».

Для архітектурних рішень іноді достатньо короткого запису «контекст — варіанти — рішення — наслідки». Репозиторій MADR наводить такий шаблон; він допомагає передати причину рішення, а не тільки останній вибір. Початкова стаття авторів MADR описує проблему розходження зовнішньої документації з кодом і повідомляє про ранню перевірку шаблону в одному відкритому проєкті; автори називають результати перспективними, але такими, що потребують подальших удосконалень. Це конкретний дослідницький приклад, а не універсальний доказ користі окремого запису для кожної команди (Kopp, Armbruster і Zimmermann, 2018). У поточній документації MADR передбачені контекст, рішення, наслідки та метадані. Водночас не кожен чат має ставати ADR. Критерій простий: чи важливо майбутньому читачеві знати це рішення, його межі та чому його ухвалили?

25.7. Як агент має знаходити й цитувати знання

Коли агенту потрібен факт про проєкт, надійна послідовність така:

визначити, яке саме питання треба розв’язати;
знайти й відкрити першоджерело, а не зупинятися на пошуковому фрагменті чи підсумку;
прочитати пов’язаний розділ, історію або залежний запис, необхідний для меж задачі;
перевірити гілку/коміт, номер редакції, дату, статус схвалення, середовище й права доступу;
відповісти із точним шляхом до файла, ідентифікатором запису, уніфікованою адресою ресурсу (URL, uniform resource locator), комітом, заголовком розділу або часовим інтервалом;
відокремити те, що прочитано, від того, що лише припускається, і назвати неперевірені системи.

Пошуковий індекс — засіб знаходження, а не остаточний авторитет. Якщо індекс знайшов фрагмент, слід відкрити відповідний файл і перевірити контекст, дату та статус. Якщо агент не має прав на сам документ або історію, він має так і сказати: «бачу посилання, але не зміг перевірити вміст», а не повідомляти переказ як факт.

Вміст зовнішнього документа — дані для аналізу, а не автоматичне повноваження виконувати вбудовані інструкції. Текст політики може містити правило, важливе для відповіді, але в ньому може бути і цитата, зразок, історичний уривок або випадковий рядок «агенте, проігноруй попередні вказівки». Спершу встановіть, хто створив документ, його статус і призначення; дотримуйтеся правил повноважень поточного завдання та безпеки. Інструкції репозиторію можуть скеровувати роботу в цьому репозиторії, а коментар у чужому вкладенні не може самостійно дозволити передачу секретів або зміну продуктового правила. У документації Codex і Claude Code також розрізняються інструкції проєкту й допоміжна пам’ять, а інструкції текстового файла не є технічним контролем дозволів OpenAI описує складання інструкцій для Codex; Anthropic розрізняє файли CLAUDE.md та автоматичну пам’ять Claude Code.

Правильний звіт також розділяє час:

«Я пам’ятаю з чату за вчора, що реліз планували на гілку release/2.1».
«Сьогодні я відкрив GitHub і перевірив, що pull request №84 досі відкритий на коміті a1b2c3d, а тег розгортання в передвиробничому середовищі указує на 9f8e7d6».

Перша фраза повідомляє про спогад, а не поточний факт. Друга — про конкретні свіжі перевірки. Та сама дисципліна стосується актуального pull request, основної гілки, розгортання, конфігурації чи запису в базі. Якщо джерело не читалося сьогодні, не створюйте враження, що його стан перевірений сьогодні.

25.8. Навчальні випадки

Приклад 1. Jira каже «виконано», а футбольний сайт показує старий склад

У вигаданого сайту футбольної статистики склад — це список гравців, яких сайт показує за команду. В офіційному джерелі з’явилася транзакція: гравець з ідентифікатором 42 перейшов із Команди A до Команди B. Задача Jira просить додати підтримку нового типу таких транзакцій, щоб оновити поточний склад і зберегти попередню команду в історії. У Jira стоїть «Завершено», але посилання на pull request немає. На виробничому сайті гравець досі в складі Команди A. Керівник запитує: «Задачу завершено? Код уже прийнято? Що зараз показує сайт?»

Це три різні питання, отже треба три джерела.

«Який статус задачі в обліковому процесі?» Перевірити Jira і її історію. Якщо статус справді «Завершено», так і відповісти, але додати, що це статус запису задачі. За відсутності посилання на pull request не робити висновок, що реалізацію змерджено.
«Який код прийнято до репозиторію?» Перевірити основну гілку, історію файлів і відсутність чи стан pull request. Якщо потрібного коміту немає, у GitHub немає доказу, що виправлення ввійшло в основну гілку. Наявність коду в локальній копії розробника не змінює цього висновку.
«Що бачить відвідувач сайту зараз?» Перевірити поточне середовище: ідентифікатор розгорнутого артефакту, ціль конфігурації та контрольний запит до маршруту складу й історії транзакцій. Якщо сторінка все ще показує гравця в Команді A, сказати, що перевірений виробничий склад наразі старий, указати час і метод. Історичний запис про попередню команду сам по собі не доводить, що поточний склад оновлено.

Після цього повідомити про суперечність власнику задачі: «У Jira стоїть “Завершено”, але доказ злиття відсутній, а контрольний запит до виробничого сайту на час Х досі показує гравця в Команді A. Перевірте, чи задача закрита помилково, чи зміна ще не була запланована до розгортання». Не переводити Jira в інший статус і не запускати розгортання лише на підставі здогаду. Після пояснення відповідальна людина або встановить фактичний статус роботи, або додасть pull request і крок розгортання; далі треба перевірити новий стан відповідними системами.

Висновок: Jira відповіла про робочий процес задачі, GitHub — про код, виробничий сайт — про поточний склад. Жодна система не скасовує факти з двох інших.

Приклад 2. Схвалена політика у Drive суперечить README, а в чаті є непідтверджене уточнення

Уявна схвалена політика у Drive, редакція 4, від 12 серпня, каже: «Знижка 10% доступна лише для плану “Річний”». У README.md сказано: «10% для щомісячної оплати». У чаті сьогодні менеджер написав: «Здається, клієнту пообіцяли 15% незалежно від плану», але ні власник політики, ні сам клієнт це не підтвердили.

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

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

Після підтвердження уповноваженої особи команда фіксує або індивідуальний виняток у системі договорів/клієнтських записів, або нову редакцію загальної політики в Drive. У README додають посилання та короткий узгоджений переказ. Якщо запис у Jira впливає на реалізацію, його критерії теж оновлюють. Стару редакцію не затирають: позначають, що саме й від якої дати її замінило. Якщо ж підтвердження так і немає, це лишається відкритим рішенням, а не фактом, який агент «логічно» вивів із чату.

Приклад 3. Підсумок агента пропустив заборону на персональні дані

Уявімо, попередня сесія агента залишила зручний підсумок: «Експортуй вибірку клієнтів у таблицю, щоб перевірити відмови підписки». Підсумок не згадує обмеження: політика безпеки забороняє завантажувати імена, адреси електронної пошти та інші персональні дані до персональних таблиць. У новій сесії агент бачить задачу Jira про аналіз причин відмови й старий підсумок.

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

У звіті агент прямо зазначає: «Попередній підсумок не містив обмеження на персональні дані. Перед дією перечитано політику редакції X від дати Y. Особистий експорт не виконувався. Для продовження потрібен схвалений набір/середовище». Після цього власник знання може виправити шаблон передачі роботи й, якщо доцільно, доповнити пам’ять посиланням на політику. Така нотатка зменшить шанс пропуску, але наступний агент однаково має перевірити поточне правило.

Висновок: підсумок допомагає продовжити роботу; він не скасовує чинну політику та не видає доступу до персональних даних.

Приклад 4. Аналітика відмов без особистого експорту

Команда хоче з’ясувати причини скасування підписки. Jira просить експортувати вибірку клієнтів, але не визначає дозволених полів. Схвалена політика забороняє зберігати імена й адреси в особистих таблицях; затверджене аналітичне середовище має набір із агрегованими або псевдонімізованими даними. Перевір сферу політики, поля набору та дозволи середовища. Використовуй лише підтверджені дані в цьому середовищі; якщо умови або ризик повторної ідентифікації неясні, спитай власника даних перед експортом. У звіті назви перевірену редакцію політики й те, які дані фактично використано.

25.9. Мінімальна політика власності знань

Команді достатньо коротких домовленостей, які відповідають на чотири запитання:

Що треба визначити	Мінімальне правило
Де це живе?	Вимоги й статус задачі — у Jira; версії коду та документації про розробку — у Git; обговорення й огляд зміни — у pull request; доменні записи — у визначеній базі/сервісі; схвалені робочі чи клієнтські матеріали — у визначеній папці Drive; домовленість, яку треба пам’ятати довше за чат, — у канонічному записі, на який чат посилається.
Хто може схвалити чи змінити?	Назвати власника правила та його заступника. Виконавець може запропонувати текст, але не підміняє схвалення. Для технічного рішення визначити рецензента або команду.
Коли оновлювати?	Після зміни політики, критеріїв приймання, коду, схеми даних, програмного інтерфейсу застосунку (API, application programming interface), розгортання чи процедури — оновити відповідні похідні записи. У кожному головному документі перелічити події, які запускають перегляд.
Як виправляти копії?	Похідний запис має посилання, версію джерела й власника; після зміни канону його синхронізують автоматично або перевіряють за явним списком. Якщо копію не встигли оновити — позначити як застарілу, не видавати за чинну.

Не треба створювати окремий повний посібник для кожної зміни. Невелике виправлення помилки може потребувати лише задачі й pull request. Виняток із політики, зміна контракту або рішення з довгим життям варте окремого запису з контекстом, авторитетом і датою. Завдання наступної глави про передавання роботи — передати не всі історичні повідомлення, а ціль, фактичний стан, відкриті рішення та посилання на джерела. У главі 27 ми окремо навчимося орієнтуватися в репозиторії; ця глава пояснює, чому пошук файла ще не підтверджує його чинність.

25.10. Підсумок

«Джерело правди» має сенс лише з уточненням: джерело для якого твердження, області та часу. Система обліку зберігає авторитетні записи свого типу; поточний стан показує, що працює зараз; журнал допомагає відтворити історію; зручна копія допомагає орієнтуватися, але може застаріти.

Вимоги, код, обговорення реалізації, доменні дані, схвалені матеріали, робоча розмова й пам’ять агента мають різні ролі. Автор, дата, версія, межі, схвалення, доступ і походження пояснюють, чому запису можна довіряти для конкретного питання. Новіший текст не автоматично замінює старе схвалене рішення; чернетка не стає політикою лише через дату.

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

Джерела

Онлайн-документацію, що може змінюватися, перевірено в період 23–26 вересня 2026 року; коли джерело не показує дату публікації чи версії, це зазначено. Наведені приклади конфліктів і всі записи Jira, GitHub, Drive, бази даних та виробничого середовища в цій главі вигадані й навчальні.

GitHub, About Git, поточна документація без видимої дати публікації; перевірено 26 вересня 2026 року. Використано для пояснення, що репозиторій містить файли та історію ревізій; Git-джерело треба називати разом із гілкою та комітом.
GitHub, Viewing and understanding files, поточна документація без видимої дати публікації; перевірено 26 вересня 2026 року. Використано для можливостей перегляду вихідного файла без форматування, історії рядків (blame) й історії файла з автором, повідомленням і датою коміту.
GitHub, Pull requests, поточна документація без видимої дати публікації; перевірено 26 вересня 2026 року. Описує pull request як пропозицію з обговоренням та оглядом, що має вкладки комітів, перевірок і змінених файлів.
Atlassian, What are the different types of activity on a work item?, поточна документація Jira Cloud без видимої дати публікації; перевірено 26 вересня 2026 року. Використано для розрізнення коментарів, історії редагувань і переходів, а також журналу часу. Це опис Jira Cloud, а не гарантія правильності введеного статусу.
OpenAI, Michael Bolin, Unrolling the Codex agent loop, 23 січня 2026 року; перевірено 23 вересня 2026 року. Описує, як Codex збирає інструкції, включно з AGENTS.md, а також їхній розмір і порядок. Це конкретний опис Codex на дату публікації, а не універсальна поведінка кожного агента.
OpenAI Developers, Eric Provencher, Rethinking skills and prompts for GPT-6 Astra, 11 вересня 2026 року; перевірено 23 вересня 2026 року. Використано для принципу цільового читання репозиторних інструкцій і регулярного перегляду застарілих правил; це рекомендація OpenAI для зазначеного сімейства моделей, а не незалежний експеримент.
Anthropic, How Claude remembers your project, поточна документація без видимої дати публікації чи версії; перевірено 23 вересня 2026 року. Описує відмінність між інструкціями CLAUDE.md та автоматичною пам’яттю, їхню область і спосіб завантаження. Налаштування Claude Code не слід переносити на інші агенти.
Гербер, Майкл Е., The E-Myth Revisited: Why Most Small Businesses Don't Work and What to Do About It, переглянуте й доповнене видання/перевидання HarperCollins, 2009, 288 с., запис Google Books; сторінка книжки. Переглянуто бібліографічні дані й обмежений опис видання, а не повний текст; повного доступу до книги тут не було. Для прикладного пояснення систематизації процесу додатково перевірено недатований матеріал команди EMyth, Create your Small Business Prototype, і недатований огляд 3 Groundbreaking Ideas from “The E-Myth Revisited”. Це матеріали команди EMyth, не окрема авторська цитата Гербера. Перенесення ідеї систематизації процесів на власність документації — висновок цієї глави.
Клеппманн, Мартін і Кріс Ріккоміні, Designing Data-Intensive Applications, 2-ге видання, O’Reilly Media, лютий 2026 року, міжнародний стандартний номер книги (ISBN, International Standard Book Number) 9781098119058; сторінка книжки та [доступний попередній перегляд розділу 1](https://www.oreilly.com/library/view/designing-data-intensive-applications/9781098119058/ch01.html), перевірено 26 вересня 2026 року. У переглянутому фрагменті та змісті перевірено опис компромісів між різними сховищами і назву розділу «Systems of Record and Derived Data»; повний текст книги недоступний у цьому дослідженні, тому висновки обмежено доступним переглядом. Приклад із похідною документацією є аналогією до термінів книги, а не обіцянкою транзакційної узгодженості документів.
Kopp, Oliver, Anita Armbruster та Olaf Zimmermann, “Markdown Architectural Decision Records: Format and Tool Support”, праці 10-го Центральноєвропейського воркшопу з сервісів та їх композиції — Central European Workshop on Services and their Composition (ZEUS), Дрезден, 8–9 лютого 2018 року, с. 55–62; метадані публікації перевірено 26 вересня 2026 року. Науковий опис структурованого запису архітектурного рішення. Для поточного прикладу використано реліз MADR 4.0.0, README за тегом, повний шаблон і мінімальний шаблон; перевірено 23 вересня 2026 року. Для історії назви звірено changelog. Ця версія й один публічний шаблон — приклад, а не норматив для всіх команд.

Межі джерел і висновків. Документація GitHub, Jira, OpenAI й Anthropic описує можливості та поведінку саме своїх продуктів у версіях на момент перегляду; вона не доводить актуальність конкретного файла, статусу, середовища чи інтеграції проєкту. Бібліографічні дані та відкриті матеріали EMyth не дорівнюють повному прочитанню The E-Myth Revisited. Доступний зміст і фрагмент DDIA 2 не замінюють повного тексту; порівняння з документацією навмисно обмежене поняттями первинного запису, похідного представлення й свіжості. Репозиторій MADR є одним публічним прикладом, а не емпіричним доказом переваги ADR для будь-якого рішення.