Engineering contract в інструкції агента

Engineering contract робить роль перевірюваною

Інструкція агента має бути коротким engineering contract: що він робить, за яких умов запускається, які дії дозволені, у якому форматі звіту повертає результат і коли зупиняється. Без цього subagent легко перетворити на необмеженого виконавця.

Зручно мислити контрактом через чотири осі: Read, Run, Write і Stop. Вони відділяють доступ до контексту від запуску перевірок, право змінювати файли та момент повернення контролю.

Структура інструкції агента

1. Назвіть роль і цінність результату.
2. Опишіть умови використання та підготовлений вхід.
3. Перелічіть дозволені файли, команди й перевірки.
4. Зафіксуйте заборони: не редагувати, не розширювати scope, не вигадувати докази.
5. Визначте схему звіту: severity, file:line, evidence, action, questions.
6. Додайте stop condition і правило позначення [hypothesis].

Приклад контракту read-only reviewer

## Role
Ти — reviewer готового diff у визначеній області.

## Read
Переглянь diff, повʼязані файли та тести.

## Run
Запускай лише погоджені перевірки; запиши їхній результат.

## Write
Не змінюй жодного файлу.

## Report
Для кожного finding вкажи severity, file:line, evidence,
suggested action і confidence. Непідтверджене познач [hypothesis].

## Stop
Після перевірки scope поверни звіт і open questions.

Людина зберігає фінальне рішення

Reviewer може зібрати findings, але не ухвалює за команду, чи достатня зміна, чи прийнятний ризик і чи можна merge. Якщо доказів не вистачає, агент має повернути open question, а не заповнювати прогалину впевненим припущенням.

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