Контракт задачи

Эта глава — про управление работой coding- или knowledge-agent человеком, а не про внутренний runtime contract между model, tools и state store. Хорошая постановка описывает не только действие, но и границы самостоятельности. Контракт задачи — это компактное соглашение о результате, полномочиях и доказательствах завершения.

Он не обязан быть формальным документом. Для небольшой задачи достаточно нескольких строк. Важно, чтобы существенные неопределённости были либо разрешены, либо явно оставлены для discovery.

Если вы проектируете исполняемую agentic-систему, используйте эту форму как human-facing task brief, а runtime-механику сверяйте с agent loop and state и tools and effects.

Поля контракта

Поле	На какой вопрос отвечает
Outcome	Какое состояние должно стать истинным?
Current state	Откуда начинаем и что уже известно?
Scope	Какие компоненты и действия входят в работу?
Non-goals	Что намеренно не решаем?
Constraints	Какие свойства нельзя нарушить?
Authority	Что агент может делать без нового разрешения?
Acceptance criteria	Какие наблюдения докажут результат?
Evidence	Какие источники считаются авторитетными?
Escalation	При какой неопределённости нужен человек?
Stop conditions	Когда работа обязана прекратиться?

Outcome вместо списка действий

Список шагов быстро устаревает после discovery. Outcome позволяет агенту адаптировать путь.

Слабо:

Добавь Redis, перепиши сервис и сделай кэш.

Лучше:

Повторные чтения профиля не должны обращаться к основной базе в течение 60 секунд, при этом пользователь всегда должен видеть собственное последнее изменение. Сначала измерь текущую нагрузку и сравни минимум два способа.

Во втором варианте Redis может оказаться подходящим решением, но контракт не подменяет цель заранее выбранной технологией.

Scope и non-goals

Scope отвечает «где работаем», non-goals — «какую соседнюю проблему не захватываем».

Scope:
- API чтения профиля;
- слой доступа к данным;
- тесты и метрики этого пути.

Non-goals:
- общая платформа кэширования для всех сервисов;
- редизайн модели пользователя;
- миграция других endpoints.

Non-goals защищают от добросовестного scope creep: агент может увидеть привлекательное улучшение, которое не приближает текущий outcome.

Constraints: инварианты, а не лозунги

Полезное ограничение можно проверить или применить к решению:

• публичный API остаётся обратно совместимым;
• существующие пользовательские заметки не удаляются;
• внешние письма нельзя отправлять без approval;
• новая зависимость должна поддерживать Node 24;
• p95 не хуже заданного порога;
• персональные данные не покидают указанный контур.

Фразы «сделай качественно», «используй best practices» или «не сломай ничего» не помогают выбрать между вариантами.

Authority: не только список инструментов

Полномочия состоят из нескольких измерений:

Можно без согласования:
- читать репозиторий и историю Git;
- запускать локальные проверки;
- менять файлы в текущей ветке.

Нужно согласование:
- добавление платного сервиса;
- изменение публичного контракта;
- push, публикация или внешнее сообщение;
- удаление пользовательских данных.

Лимиты:
- работать только в этом репозитории;
- не изменять unrelated user changes;
- остановиться после двух неудачных вариантов миграции.

Публичный OpenAI Model Spec использует похожую идею bounded scope of autonomy: допустимые подцели, побочные эффекты и моменты обязательной паузы должны быть взаимно понятны человеку и агенту. Это пример политики конкретного провайдера, но сама структура полезна как переносимая модель: Act within an agreed-upon scope of autonomy (версия от 2026-08-18).

Acceptance criteria: что способно опровергнуть «готово»

Критерий должен описывать наблюдение, а не усилие:

Непроверяемо	Проверяемо
Обновить зависимости	Чистый install и production build проходят на Node 24
Улучшить документацию	Новый читатель выполняет сценарий без дополнительного контекста
Исправить ссылку	Из /intro переход ведёт на существующий root-relative route
Сделать безопасно	Внешняя запись невозможна без нужного permission/approval
Сохранить информацию	Coverage matrix отображает каждое исходное утверждение

Хорошая проверка может завершиться неуспехом. Если критерий всегда можно объявить выполненным словами, он не защищает контракт.

Escalation и stop conditions

Агент должен знать, когда самостоятельность перестаёт быть полезной.

Эскалация нужна, если:

• обнаружены конфликтующие требования одинакового приоритета;
• выбор меняет продуктовый смысл, стоимость или публичный контракт;
• требуется действие за пределами authority;
• авторитетный источник недоступен;
• проверка показывает, что одобренный подход не работает.

Остановка нужна, если:

• достигнут outcome и выполнены acceptance criteria;
• дальнейшее действие необратимо и не разрешено;
• повторяется одна и та же ошибка без нового evidence;
• исчерпан заданный бюджет времени, стоимости или попыток;
• среда изменилась так, что исходный контракт больше неприменим.

Полный пример

# Task contract: новый раздел о работе с агентами

Outcome:
Читатель понимает, как задать задачу, собрать контекст, ограничить
автономность и проверить результат; сайт ведёт в этот раздел первым.

Current state:
Docusaurus-сайт содержит в основном технические cheatsheets.
Навигация автогенерируется из docs/ и _category_.json.

Scope:
- новая категория Agentic Engineering;
- главная страница, Intro и metadata;
- инфраструктура, необходимая для проверяемой сборки.

Non-goals:
- переписывание старых cheatsheets;
- обещание универсальных prompts;
- реальный production deploy без внешних secrets.

Constraints:
- сохранить каждый старый route;
- новый материал на русском и provider-neutral;
- изменчивые claims подтверждать primary sources;
- не использовать force-обновления зависимостей.

Authority:
Можно менять файлы репозитория и запускать локальные проверки.
Нельзя публиковать, удалять пользовательские заметки или расширять scope.

Acceptance:
- production build и typecheck зелёные;
- baseline route manifest полностью сохранён;
- новая категория и восемь страниц доступны;
- browser smoke test проходит;
- semantic review не находит потери исходного intent.

Escalation:
Спросить пользователя, если новая структура требует удалить старый материал
или выбрать другое публичное позиционирование сайта.

Stop:
Остановиться при необходимости внешних credentials или необратимого действия.

Шаблон короткого контракта

Нужный результат:

Текущее состояние и evidence:

В scope / вне scope:

Инварианты:

Можно делать самостоятельно:

Требует согласования:

Проверка завершения:

Остановиться или спросить, если:

Не заполняйте поле ради полноты. Если у задачи нет внешних действий, раздел approval может состоять из одной строки.

Pre-run checklist

• Outcome описывает состояние, а не любимую реализацию.
• Scope имеет границу, non-goals защищают от расползания.
• Constraints применимы к конкретным решениям.
• Authority различает чтение, локальную запись, внешнюю запись и удаление.
• Acceptance criteria наблюдаемы и способны упасть.
• Evidence имеет источник и дату/версию, если может устареть.
• Escalation оставляет человеку только существенные решения.
• Stop condition предотвращает бесконечные повторы и неразрешённые действия.