63 lines
5.7 KiB
Markdown
63 lines
5.7 KiB
Markdown
# 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, если он подходит.
|