Контракт завдання для агента

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

У попередній главі короткий робочий бриф був лише одним кроком у повному проходженні вертикального зрізу. Тут ми зосередимося на самому завданні: як зв’язати бажаний результат із поточним станом репозиторію, джерелами вимог, межею дозволеної роботи, доказами та правом ухвалювати рішення. Це продовжує теми вимог і критеріїв із глав 8–10, але не замінює їх: контракт посилається на наявну специфікацію й визначає, що саме виконавець робить із нею в конкретній робочій копії. Координація кількох виконавців докладніше розглянута у главі 38. Контракт називає репозиторій і потрібне середовище; наступна глава 47 окремо пояснює, що робоче дерево Git, контейнер і тестові дані справді ізолюють, а що лишається спільним.

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

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

46.1. Контракт — це узгоджена межа роботи

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

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

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

Це близько до поради Райана Сінгера в Shape Up: формувати проблему, «апетит» — скільки часу команда готова вкласти в роботу, — окреслення рішення, ризикові невідомі й свідомі «no-gos», тобто речі поза роботою. Апетит обмежує форму рішення; це не оцінка тривалості вже визначеної реалізації й не довільний дедлайн. Окреслення має дати виконавцям напрям і межу, а не вдавати, що кожна реалізаційна деталь відома заздалегідь. Це метод Basecamp, а не обов’язковий процес для будь-якої команди. У практиці агентської розробки з нього корисно взяти дві ідеї: явно назвати виключені сценарії та не приховувати ризикові припущення (Shape Up: Write the Pitch, Shape Up: Risks and Rabbit Holes).

46.2. З чого складається придатне завдання

У конкретному завданні поля можуть бути короткими або посилатися на наявний документ. Їхня мета — не заповнити форму, а прибрати неоднозначність, що вплине на рішення.

Мета і цінність

Опишіть зміну, яку має відчути користувач або оператор, і навіщо вона потрібна. Формулювання «додати кнопку» називає роботу інтерфейсу; «оператор може повторно запустити невдалий імпорт без втрати вже прийнятих записів» називає результат і збережувану властивість.

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

Поточний стан і джерела

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

Поруч назвіть авторитетні джерела: наприклад, узгоджену вимогу, рішення архітектора (ADR, Architecture Decision Record — запис архітектурного рішення), контракт програмного інтерфейсу застосунку (API, Application Programming Interface), правила репозиторію або офіційну документацію постачальника. Дайте посилання на конкретний розділ чи версію, коли це можливо. Не треба вставляти весь документ, якщо достатньо посилання й короткого пояснення, чому воно важливе.

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

Межі й інваріанти

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

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

Критерії приймання і докази

Критерій має описувати спостережувану умову. «Тести проходять» неповне, якщо не зрозуміло, які перевірки, на якій ревізії й яку властивість вони підтверджують. Для кожного важливого критерію назвіть відповідний доказ: перевірка, огляд diff, запис журналу, запит до тестового середовища або інше спостереження.

Зручно розділяти чотири стани доказу. Це рекомендована лексика звіту, не спільний протокол агентських продуктів:

Статус	Що він означає
PASS	Перевірку виконано, і отриманий результат відповідає критерію.
FAIL	Перевірку виконано, але результат суперечить критерію або виявив дефект.
BLOCKED	Перевірку неможливо завершити в наявних умовах через конкретну відсутню передумову чи доступ; назви, що саме блокує.
NOT RUN	Перевірку не запускали, хоча вона була доступною або її свідомо відклали; назви причину. Це не доказ проходження.

«Не запустив через відсутній тестовий обліковий запис» — це не PASS і не обов’язково дефект коду. Це невиконана перевірка з конкретним блокером, який відповідальний власник може усунути або прийняти як залишковий ризик. Старий результат не переноситься на нову ревізію, якщо між ними змінилися код або передумови.

Дозволи, передумови та межа зупинки

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

Текст завдання пояснює намір, але не видає технічних прав. Реальні можливості залежать від інструментів, ізоляції й налаштувань схвалення конкретного середовища. Наприклад, документи OpenAI розрізняють межі середовища виконання та контроль дозволів, а Claude Code має окрему систему правил дозволу, запиту або заборони інструментальних дій. Це різні продукти й конфігурації; не можна переносити поведінку одного на інший (OpenAI: Agent approvals & security, Anthropic: Configure permissions, перевірено 26 вересня 2026 року).

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

Ресурси й очікуваний звіт

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

Наприкінці визначте форму звіту. Потрібні не лише список команд або «готово», а:

• що змінилося, де й навіщо;
• яка базова та фінальна ревізія розглядалася;
• які критерії й перевірки отримали PASS, FAIL, BLOCKED або NOT RUN;
• які невідомі, ризики й рішення лишилися;
• який наступний крок потрібен від власника.

Anthropic радить давати агенту спосіб перевірити результат і показувати докази, наприклад результати тестів чи збірки. OpenAI у рекомендаціях для Codex Goals також пов’язує завершення роботи з чітким результатом, способом перевірки та явними умовами зупинки. Це поради виробників для їхніх продуктів, а не гарантія правильності й не доказ, що існує один оптимальний формат доручення (Anthropic: Best practices for Claude Code, OpenAI: Using Goals in Codex, перевірено 26 вересня 2026 року).

46.3. Повний приклад: «виправити проблему з бронюванням»

Ситуація. Власник продукту каже: «Клієнти не можуть перенести бронювання; виправ це». У репозиторії є кілька типів бронювань, а з повідомлень підтримки незрозуміло, чи йдеться про прострочені записи, групові заняття або гонку за один вільний час. Однієї фрази недостатньо для безпечного редагування.

Домовленість перед роботою. Автор перевіряє проблему з підтримкою та власником продуктового правила. Для навчального сценарію вони погодили: клієнт може перенести власне майбутнє підтверджене індивідуальне бронювання на інший доступний час; після початку візиту — ні. Сценарій групового заняття й автоматичне повідомлення SMS (Short Message Service — служба коротких текстових повідомлень) не входять до цієї зміни. Наведені нижче документи й назви — умовні.

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

Поточний стан. Репозиторій service-booking, гілка main, перевірена базова ревізія abc1234. Зараз екран показує доступні години, але при одночасному виборі двома клієнтами обидва можуть отримати оптимістичне повідомлення про успіх. Перед редагуванням перевір актуальну гілку й локальні незбережені зміни.

Джерела. Продуктове правило в A1M-214; узгоджений контракт Booking API версії 3; архітектурне рішення ADR-12 щодо джерела істини часу; правила репозиторію. Якщо вони суперечать одне одному або код показує інше правило, зупинись і назви конфлікт.

У межах. Для одного майбутнього індивідуального бронювання: серверна перевірка власника й статусу, повторна перевірка доступності під час збереження, правдивий стан інтерфейсу та зрозуміле повідомлення, коли час уже зайняли.

Поза межами та інваріанти. Групові заняття, оплата, повідомлення SMS, календарна синхронізація й рефакторинг інших типів запису поза межами. Не можна змінити чуже бронювання, втратити чинний запис через конфлікт або показати успіх до підтвердженого збереження.

Критерії та докази. (1) Власник переносить своє придатне бронювання й бачить новий час після повторного читання з сервера. (2) Інший користувач не може прочитати чи перенести його бронювання. (3) Два запити на останній вільний час не обидва завершуються успіхом; той, що програв, лишає старий запис незмінним і бачить відновлювану помилку. (4) Бронювання після початку візиту не змінюється. До звіту додай результати наявних відповідних перевірок і ревізію, на якій їх отримано; якщо тестове середовище недоступне, познач перевірку окремо.

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

Звіт. Файли й поведінка, базова та перевірена ревізії, таблиця критеріїв із PASS/FAIL/BLOCKED/NOT RUN, фактичні результати команд, невирішені рішення й наступний потрібний крок.

Чому з’явилися ці пункти. Мета відокремлює вигоду для користувача від списку активностей. Поточний стан дає точку порівняння, але агент ще має перевірити її в копії. Джерела вказують, який документ визначає продуктове правило та який — технічний обмін. Обсяг відсікає спокусливі суміжні функції. Інваріанти захищають цілісність, навіть якщо виконавець обере іншу структуру коду. Критерії перетворюють слова «виправити» й «працює» на поведінку, яку можна спостерігати. Повноваження відокремлюють написання коду від зовнішніх дій. Звіт прив’язує твердження до ревізії й показує те, що залишилося невідомим.

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

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

46.4. Коли знайдено роботу за межами контракту

Ситуація. Під час роботи над екраном повторного запуску імпорту агент виявляє, що публічний API не має операції для часткового відновлення. Внутрішня черга має стан, який неможливо безпечно представити в поточному контракті. Зміна API розв’язала б проблему, але змінює обсяг і може зачепити інтеграції клієнтів.

Неправильне рішення. Агент додає endpoint (точку API, через яку клієнт викликає операцію) і нову відповідь до API, оновлює клієнт та випускає це як частину маленького завдання на користувацький інтерфейс (UI, User Interface — частина програми, з якою взаємодіє користувач). Навіть якщо реалізація технічно правильна, сам виконавець вирішив питання сумісності, яке належить власнику публічного контракту. Інший неправильний варіант — приховати проблему, зімітувавши успішний повторний запуск, який не відновлює частково завершені записи.

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

У погодженому обсязі можу додати екран, який показує стан черги й дозволяє повторний запуск лише для повністю невдалого імпорту. Для частково обробленого файлу наявний API не визначає ні безпечної семантики повтору, ні ідемпотентності (повтор того самого запиту не має створювати новий ефект) для вже збережених записів. Перевірив контракт версії 3 і точку API POST /imports/{id}/retry; обидва описують лише повний повтор. Варіанти: (A) лишити частковий стан недоступним у цій зміні й окремо подати пропозицію розширення API; (B) розширити контракт після рішення власника й додати докази сумісності клієнтів. Нічого не змінював у публічному API. Який варіант затверджує власник контракту?

До рішення власника ця частина роботи зупинена; незалежні зміни початкового обсягу можуть тривати лише якщо не залежать від неї. У навчальному випадку власник API обирає варіант A: часткове відновлення не входить до цієї зміни, а підтримку пропонують окремим завданням. Автор фіксує це рішення й межу в контракті; агент завершує лише екран і повторний запуск повністю невдалого імпорту. Або власник міг би затвердити B, додати вимогу, критерії сумісності, перелік споживачів і потрібні дозволи. Якщо після рішення змінюється контракт, автор оновлює домовленість до реалізації, а не лише додає факт у фінальний звіт. Критерії початкового завдання не послаблюють заднім числом, щоб приховати незавершену поведінку.

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

46.5. Коли перевірку заблоковано

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

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

Чесний звіт прив’язує результат до виконаних дій:

Критерій	Статус	Спостереження
Повторна обробка валідного файлу з локальними фікстурами не створює дублікати	PASS	Локальну перевірку виконано на коміті d47c21a; отримано 0 дублікатів у результаті фікстури.
Реальний тестовий постачальник віддає файл у погодженому форматі	BLOCKED	Інтеграційну перевірку не запускали: немає тестового облікового запису й адреси середовища.
Сценарій із повтором після тайм-ауту	BLOCKED	Не перевірено через ту саму відсутність тестового доступу; результат потрібен, щоб підтвердити відновлення після тайм-ауту.

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

Приклад показує, що звіт розділяє факт виконання перевірки, її результат та стан критерію. Обидві інтеграційні перевірки BLOCKED, бо їх зараз неможливо виконати через відсутній доступ. Окремий необов’язковий тест продуктивності, який не запитували й не запускали, мав би статус NOT RUN; він не є доказом ні успіху, ні невдачі імпорту. Перевірка, яку не запускали, не «напевно пройшла»; водночас блокер доступу не є свідченням дефекту. Рішення про прийняття залишкового ризику належить відповідальному власнику, а не тому, хто не зміг запустити перевірку.

46.6. Коли коротше краще, а коли потрібен план

Докладність має зменшувати ризик, а не збільшувати кількість тексту. Для малого завдання достатньо одного речення результату, посилання на проблему, обмеження «не змінюй поведінку X» і однієї перевірки. Для зміни з багатьма файлами, розбіжними джерелами чи зовнішніми наслідками варто спершу попросити агента дослідити стан і представити план або відкриті питання до редагування. Anthropic також радить дослідження й планування для широкої невизначеної зміни, але зазначає, що очевидні маленькі правки не потребують зайвого плану (Best practices for Claude Code).

Порада OpenAI для GPT-6 Astra — давати потрібний контекст і вказувати, які документи допомагають із конкретним рішенням, а не змушувати модель перечитувати весь репозиторій перед кожною правкою. У первинній статті також застерігається, що надмірний контекст може відволікати; це рекомендація для конкретної моделі, опублікована 11 вересня 2026 року, а не гарантія, що коротший запит завжди кращий (Rethinking skills and prompts for GPT-6 Astra).

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

46.7. Реальний приклад: повідомлення про помилку і межа висновку

Бібліотека Python asyncio виконує мережеві операції через цикл подій. Селектор повідомляє циклу, що сокет готовий до читання чи запису; транспорт керує сокетом і сповіщає програму, коли з’єднання закрилося. У звіті CPython №156512 відтворено збій під час відновлення запису (resume_writing()): протокол пише наступний фрагмент, а після завершення джерела закриває з’єднання. Код повторно входить у завершення з’єднання й двічі викликає _call_connection_lost() — сповіщення про закриття; обробник помилок циклу отримує виняток. Автор навів кроки відтворення, очікувану та фактичну поведінку, версії й огляд шляху виконання. Він окремо застеріг, що схожий ризик у _SelectorDatagramTransport._sendto_ready, шляху відправлення окремих мережевих повідомлень, помітив під час читання коду, але не перевірив. Це корисна відмінність: «відтворив», «побачив у diff» і «підозрюю за аналогією» — різні рівні доказу; у його тесті потоковий API не показав цього збою.

Пов’язаний PR Python №156657 виправив обидва шляхи запису — _write_send і _write_sendmsg — та додав окремі регресійні перевірки, де connection_lost() має викликатися рівно один раз, а обробник помилок циклу — не спрацьовувати. Він також додав запис до журналу змін Python. PR не охоплює неперевірений шлях датаграм і не доводить, що той шлях безпечний. На момент злиття 6 вересня 2026 року GitHub показував 99 із 101 перевірки пройденими; зведена обов’язкова перевірка була успішною. Це не те саме, що стверджувати, ніби пройшли всі перевірки.

Приклад не доводить, що кожна команда має писати однаковий звіт чи що межа цього PR була єдино можливою. Він показує цінність явно позначеного рівня доказу, сфокусованої зміни, пов’язаних регресійних перевірок і точного звіту про перевірки (Python issue №156512, PR №156657, review; перевірено 26 вересня 2026 року).

У повідомленні про проблему Claude Code №76132 користувач описує випадок, коли після ручних кроків системи неоднозначне «next» було сприйнято як дозвіл продовжити до того, як людина повідомила результат попереднього кроку. Це самозвіт без незалежно підтвердженого відтворення; issue закрито зі статусом not_planned. Його не слід подавати як доведену поведінку продукту. Як обмежений приклад він нагадує, чому передумова очікування («чекай на результат від людини») й сигнал продовження мають бути явними, якщо дія залежить від ручного стану (Claude Code issue №76132, перевірено 26 вересня 2026 року).

46.8. Як змінюється контракт

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

1. Зафіксуйте спостереження. Відокремте перевірений факт від припущення; додайте посилання на файл, ревізію, джерело чи результат команди.
2. Поясніть вплив. Що саме не можна завершити в межах чинного обсягу? Який критерій, сумісність чи ризик зачеплено?
3. Запропонуйте обмежені варіанти. Наприклад: завершити часткову поведінку без небезпечного випадку; розширити обсяг і додати докази; або зупинити роботу до рішення.
4. Отримайте рішення потрібного власника. Автор продуктового правила може не бути власником публічного API чи дозволу на виробничу дію. Визначте роль, яка справді має це право.
5. Оновіть домовленість до продовження. Зміна мети, меж, критеріїв, середовища чи дозволів фіксується в актуальному описі; звіт вказує, що саме змінилося і чому.

Це прикладне правило синтезує практику явного обсягу та перегляду ризиків із Shape Up і документування критеріїв/меж у рекомендаціях роботи з агентами. Сам Shape Up не встановлює протокол змін агентського завдання. Його принцип «не починати необмежену нову роботу в старій ставці» допомагає побачити момент, коли нове відкриття має повернути роботу на етап рішення (Shape Up: Map the Scopes, Decide When to Stop).

Короткий підсумок

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

Джерела та подальше читання

• Ryan Singer, Basecamp, Shape Up: Write the Pitch, Risks and Rabbit Holes, Map the Scopes, Decide When to Stop — авторський метод формування проблеми, обмеження, ризиків і позаобсягу. Це контекст Basecamp, а не універсальний агентський стандарт.
• OpenAI, Using Goals in Codex — результат, критерій завершення, перевірки й умова зупинки для довгих задач Codex.
• OpenAI, Rethinking skills and prompts for GPT-6 Astra, опубліковано 11 вересня 2026 року — добір релевантного контексту та явні межі в порадах для конкретної моделі.
• Anthropic, Best practices for Claude Code — контекст, планування й можливість перевірити результат у Claude Code.
• Anthropic, Configure permissions — правила дозволу, запиту або заборони дій у Claude Code; продуктова конфігурація, не загальний протокол.
• OpenAI, Agent approvals & security — розмежування безпекових меж і схвалень у продуктах OpenAI.
• CPython, issue №156512, PR №156657 і схвалення — конкретний звіт про відтворення, явну невизначеність, обмежену зміну й результати перевірок.
• Anthropic Claude Code, issue №76132 — самозвіт користувача про неоднозначне продовження після ручних кроків; не підтверджений універсальний дефект.

Посилання на мінливі інструкції та стани продуктів і репозиторіїв перевірено 26 вересня 2026 року.