5.7 KiB
Context discipline
Цель — получить правила, которые меняют текущее решение, и не читать остальные заранее. Это процедура прямой работы по задаче, без обязательных SDD artifacts, ролей, approval fingerprints или подсчёта документов как delivery gate.
Routing context
- Определи требуемое поведение, тип решения и affected repos до supporting reads.
- Прочитай root/local AGENTS, затем CONVENTIONS и SOURCES affected code repo.
- Объедини сработавшие semantic, path и boundary triggers. Путь — сигнал ответственности, а не повод загружать всё по расширению
.tsx/.ts. - Прочитай выбранные conventions или явно указанные sections до зависимого решения. При domain/API/security вопросе открой точный source через docs index.
- Проследи ближайший существующий owner и подходящие код/тесты. Его поведение не заменяет canonical fact.
- Повтори 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 для настройки новых правил. Проверяй 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, если он подходит.