Инструкции проекта

В задаче написано «добавить отчёт для врача», в правилах проекта запрещён экспорт личных данных, а в старом чате есть просьба отправлять отчёт по почте. Если передать агенту все три текста без пояснения их роли, он получит противоречивую постановку.

Разделение инструкций начинается с простого вопроса: кто принял правило и как долго оно действует?

Где хранить разные решения

В задаче остаются цель текущего изменения и его границы. В спецификации - поведение продукта, которое должно сохраниться после завершения задачи. В AGENTS.md - правила работы с репозиторием: команды тестов, расположение модулей, ограничения зависимостей. В policy runner - исполняемые ограничения доступа.

Документ	Пример из ALGI	Кто меняет
Задача в JSON	Добавить clinician_report, проверить существующие тесты.	Автор задачи; изменения объёма согласуются отдельно.
specs/pain-diary.bdd.md	Балл принимает целые значения от 0 до 10.	Владелец поведения продукта с ревью.
AGENTS.md	Использовать стандартную библиотеку Python, держать доменную логику в algi/domain.py.	Команда репозитория.
policies/local-dev.json	Разрешить runner запуск python3 -m unittest.	Владелец harness и его окружения.

Повторяемую процедуру, например разбор упавшего теста, можно вынести в skill или отдельную инструкцию. Она должна ссылаться на правила проекта, а не хранить собственную копию тех же ограничений. Личные настройки разработчика могут задавать стиль ответа, но не расширять доступы командного runner.

Противоречие нужно разрешить до работы

Единого порядка приоритетов для всех агентских инструментов нет. Конкретный CLI определяет, как он читает пользовательские, проектные и системные инструкции. Отдельно действуют ограничения операционной системы и runner: текст задачи не может сам выдать процессу права.

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

В ALGI уже есть подходящий случай. AGENTS.md требует согласовать ослабление валидации. Второй fixture меняет validate_pain_entry, добавляя удаление контактов из заметки. Это меняет сохраняемый текст. На ревью стоит выяснить, разрешалось ли такое изменение и должно ли удаление контактов происходить при вводе или только при формировании отчёта.

Инструкция и право записи

Фраза «не меняй AGENTS.md» помогает объяснить задачу. Отдельное ограничение на запись позволяет её обеспечить. Для обычной продуктовой задачи можно выдать доступ только к algi/ и tests/, сохранив спецификацию и правила проекта доступными для чтения.

Текущая учебная policy шире: она разрешает запись также в specs, AGENTS.md и README.md. Поэтому заявлять, что эти документы защищены от изменения, было бы неверно. Если вы сужаете список путей для упражнения, оформите это отдельной версией policy и проверьте отказ на запись в запрещённый файл.

Соберите карту одной задачи

Откройте algi-02-clinician-report.json и сопоставьте его context с файлами рабочей копии:

Файл	Зачем нужен	Допустимое изменение в задаче про отчёт
AGENTS.md	Правила разработки и ревью.	Только чтение.
specs/pain-diary.bdd.md	Ожидаемое поведение.	Только чтение; неясности согласовать.
algi/domain.py	Текущая реализация.	Добавление отчёта в согласованных границах.
tests/test_domain.py	Примеры уже принятого поведения.	Сохранить проверки; удаление требует объяснения.

Эта таблица описывает желаемые права для задачи; текущий runner не выводит их автоматически из списка context. В главе о доступе к инструментам разберём исполняемую часть. А сначала подготовим контекст, который агенту действительно понадобится.