6.3 KiB
Проверка agent context
Это небольшой corpus решений для настройки routing. Выполняйте cases по текущим AGENTS/router/conventions: сначала определите решение и необходимые источники, затем сравните с ожиданием. Это не unit tests, повторяющие Markdown, и не новый verification framework. Для проверки изменения правила нужны activating case, допустимое исключение и unrelated counterexample.
Cases
| Задача | Необходимый контекст / ожидаемое решение | Что не должно активироваться без новой границы |
|---|---|---|
| Изменить props и layout existing finance view | Frontend UI; props остаются presentation, derived collection values — у VM | API, Prisma, architecture, tests без risk/test change |
| Исправить только продуктовую строку/Zod message | UI section «Строки и валидация»; locale/validationMessage, mandatory review | Остальные UI sections, HTTP/structure/testing |
| Добавить page-local фильтр без сети | Frontend architecture + UI; оставить у page, если нет independent capability | Новый shared abstraction/feature ради click; API |
| Добавить business summary component | Architecture + UI; business meaning и existing owner определяют placement | shared только из-за reuse; widgets layer |
| Изменить query refetch/error recovery | Frontend data + testing; cached snapshot/current generation и exact feature source | Backend data при неизменном server behavior |
| Добавить новый HTTP response field | Backend HTTP + общий contract workflow + применимые tests; Nest → snapshot → generated TS, affected client data rules | Второй editable OpenAPI в specs; ручной generated TS |
| Добавить account endpoint с новым RPC | Backend HTTP, architecture при новом use case, security/access, integrations, testing; TbankAccessService/TbankClient | Прямой gRPC из controller; доверие accountId без ownership |
| Исправить только Prisma query без HTTP/auth boundary | Backend data, testing при data-risk; existing PrismaService | Весь HTTP/security guide автоматически |
| Атомарно обновить связанные записи | Data + testing; transaction/constraint у инварианта, isolated DB proof | Generic repository; mock как доказательство реальной atomicity |
| Изменить конкурентный refresh | Security + data + testing; ADR 009; один winner, superseded не отзывает его session | Replay-history/grace window без задачи; новый coordinator |
| Изменить DTO validation error | HTTP + testing + exact error source; configured HTTP case проверяет pipe/filter pair | Success по одному direct controller call/Swagger snapshot |
| Изменить gRPC retry/deadline | Integrations + testing; bounded existing client path, controlled upstream failure | Вложенный retry loop; реальная сеть/secret |
| Добавить безопасное scalar log field | Architecture/logging; проверить allowlist и event | Весь auth guide без sensitive boundary; считать message автоматически redacted |
| Изменить только тест | Testing соответствующего repo; source guides только по проверяемой границе | Все production conventions из-за расширения .ts |
| Добавить dependency/adapter для одной задачи | Общий выбор/dependencies; existing owner/platform/library прежде нового кода | Новый interface только для hypothetical reuse |
| Исправить опечатку в общей документации | Docs AGENTS и затронутый source | Любые frontend/backend conventions |
| После UI начала появились mutation/schema/new files | Routing повторяется по staged/unstaged/new, новые границы читаются до решения | Продолжать по первоначальному UI-only scope |
| Отсутствует обязательный security source / источники конфликтуют | Остановить зависимое решение, восстановить факт/уточнить задачу | Догадка из соседнего code или жёсткий лимит на число документов |
Что измерять
Для startup/working-set измерения перечислите ровно прочитанные файлы/sections, инструмент подсчёта и unit (символы или tokenizer). Required source нельзя исключать только ради хорошего числа. Число доступных файлов на диске не является стоимостью конкретной задачи.
Для реальной first-pass оценки выполните одинаковые задачи с одинаковой моделью, version/tools и comparable prompts: прежний context, только новые indexes, затем полный routing. Считайте принятие без substantive correction, iterations, ошибки placement/contract/security, лишние abstractions и пропущенные sources. Routing review и зелёные application tests сами по себе такого улучшения не доказывают.
Изменение правил
Если нужный source не прочитан — исправьте trigger. Если source прочитан, но не разрешает выбор — уточните decision/safe path/example. Если дефект детерминирован — используйте подходящий existing test/linter. Не добавляйте новый always-on paragraph для каждого отдельного случая.