Архитектура инструкций

В маленьком эксперименте кажется, что достаточно одного хорошего prompt. В командной работе это быстро ломается: часть правил лежит в чате, часть в README, часть в голове автора задачи, часть в CI, а policy вообще нигде явно не описана.

Агенту нужны инструкции с разным сроком жизни и разным приоритетом. Если смешать всё в один prompt, вы получите конфликтующие правила и контекст, который невозможно ревьюить.

Разложите правила по слоям

Слой	Где живёт	Как долго действует	Пример
Chat instruction	IDE/chat/CLI input	Один run	"Build the pain diary slice from this task."
Task contract	examples/harness-labs/tasks/*.json	До закрытия задачи	Acceptance criteria, checks, expected outputs.
Product spec	examples/algi-lite/specs/*.md	Долго	BDD scenarios и domain constraints.
Project rules	examples/algi-lite/AGENTS.md	Долго	Язык без medical claims, stdlib only.
Harness policy	policies/*.json	Долго, audited	Allowed commands и writable paths.
Backend skill	skill/prompt files	Переиспользуемый	Review, bugfix, docs-support сценарии.
Global profile	user/tool config	Между проектами	Личные defaults и стиль работы.

Главное правило: чем дольше живёт инструкция и чем выше её риск, тем ближе она должна быть к versioned repo или policy, а не к одноразовому чату.

Пример из ALGI

Для первого ALGI slice harness читает:

examples/harness-labs/tasks/algi-01-pain-diary.json
examples/algi-lite/AGENTS.md
examples/algi-lite/specs/pain-diary.bdd.md

А файлы ниже не являются источником истины до run. Они появляются как backend output:

examples/algi-lite/algi/domain.py
examples/algi-lite/tests/test_domain.py

Это важная граница. Generated code можно ревьюить и принимать, но он не должен сам собой переписать product spec или project rules.

Что делать при конфликте

Если инструкции спорят друг с другом, порядок такой:

1. Safety и policy.
2. Task contract.
3. Product spec.
4. Project rules.
5. Backend/chat instruction.

Например, если chat просит «быстро отправить отчёт врачу», а policy требует approval для внешних side effects, runner должен остановиться. Модель может предложить действие; границу исполняет policy.

Что сделать руками

Возьмите одну ALGI task и составьте context map:

File	Роль	Можно ли менять в этом run?
AGENTS.md	Правила проекта	нет, если task явно не разрешает
specs/pain-diary.bdd.md	Source of truth	нет, если это не задача на spec
algi/domain.py	Generated implementation	да
tests/test_domain.py	Generated verification	да

После этого проверьте, какие правила у вас сейчас живут только в голове или в старых chat prompts. Их нужно перенести в долгоживущий слой.

На что не соглашаться

• Прятать постоянные project rules в одноразовом prompt.
• Считать generated code единственным source of truth.
• Смешивать policy, product behavior и реализацию в одном файле.
• Возвращать generated output в контекст как авторитет без review.