# Context discipline

Цель — получить правила, которые меняют текущее решение, и не читать остальные
заранее. Это процедура прямой работы по задаче, без обязательных SDD artifacts,
ролей, approval fingerprints или подсчёта документов как delivery gate.

## Routing context

1. Определи требуемое поведение, тип решения и affected repos до supporting reads.
2. Прочитай root/local AGENTS, затем CONVENTIONS и SOURCES affected code repo.
3. Объедини сработавшие semantic, path и boundary triggers. Путь — сигнал ответственности, а не повод загружать всё по расширению `.tsx`/`.ts`.
4. Прочитай выбранные conventions или явно указанные sections до зависимого решения. При domain/API/security вопросе открой точный source через [docs index](../AI_INDEX.md).
5. Проследи ближайший существующий owner и подходящие код/тесты. Его поведение не заменяет canonical fact.
6. Повтори routing при новой потребности и по финальным staged, unstaged и новым файлам. Содержимое работы важнее первоначального названия задачи.

Первый проход работает без diff. Auth + refresh, например, активирует API,
security и testing вместе. Отображение query state без изменения запросов не
добавляет transport rules. Docs-only опечатка не требует frontend/backend conventions.
Обычно хватает нескольких тем; это наблюдение, не лимит. Обязательный source
нельзя пропускать ради числа файлов или token budget.

Новая граница внутри задачи требует дочитать правила до работы. Расширение
самой задачи сначала сообщи пользователю; уже данное разрешение не запрашивай
повторно. Чужой concurrent diff учитывай при разграничении ownership.

## Источники и конфликты

Прямое указание пользователя определяет задачу. Текущий executable HTTP contract
генерируется backend; docs описывает проектные факты/решения; conventions задают
выбор реализации; code показывает существующие аналоги. Generic framework advice
используется после проектных источников. Research содержит рекомендации, которые
нужно сверить с actual code/config, а не автоматически превращать в новый контракт.

Если задача намеренно меняет контракт, обновляй его source и зависимые материалы
согласованно. Missing input, противоречие security/data правил или неоднозначный
контракт блокируют только зависимое решение до установления фактов/уточнения.
История чата, случайный аналог и предполагаемый путь не заменяют источник.

## Recovery и handoff

Для продолжения достаточно текущей задачи, сделанных изменений, remaining work,
точных checks/results и blockers. Не создавай параллельную копию требований,
Design, state registry или обязательный handoff-файл.

В новом контексте восстанови необходимые sources; в том же переиспользуй уже
прочитанные неизменившиеся inputs. Supporting reads добавляй по возникшему вопросу.
Git status/diff показывают staged и unstaged; новые файлы учитывай отдельно.
Relevant ignored/workspace-owned inputs (например `.env`, root AGENTS) не
теряются только потому, что Git их не показывает. Секреты в evidence не печатай.

## Проверка эффективности

Используй [набор routing cases](agent-context-evals.md) для настройки новых правил.
Проверяй activating case, safe exception и unrelated counterexample по реальным
инструкциям. Source links и gates дополняют эту проверку, но не доказывают first-pass quality.

Сравнивай startup context и реально выбранные sections, фиксируя способ измерения.
Не объявляй меньшее число файлов или зелёный application test улучшением качества
агента. Для first-pass acceptance нужны одинаковые реальные задачи/модель/tools,
наблюдённые ошибки ownership/contract/security и число исправлений.
Добавляй convention по повторяющейся decision error; уточняй trigger при missed
source; deterministic regression отдавай существующему test/linter, если он подходит.