Refactor agent rules to progressive guidance

[karle0wne]

Тут по сути то же направление, что в #3, только правила реорганизованы так, чтобы не тащить весь набор в контекст любой задачи.

Сейчас при применении #3 на каждый запрос в AGENTS.md попадает примерно:

code-conventions.md
code-generation.md
database-conventions.md
protobuf.md              ~11 KB
profiles/adapter.md      ~15 KB суммарно

Это не только расходует token budget. Если это предполагается использовать для разных сервисов организации, модель постоянно получает правила, которые могут вообще не относиться к задаче. Например, в daway хотим просто исправить NPE, а вместе с задачей модель всё равно получает Flyway, jOOQ, transactional event delivery, soft delete, REST→gRPC gateways, converters, polling, callback replay и т. д.

Да, надо тоже отметить что плюс минус фурычить в любом случае будет - на то оно и ИИ , но нам нужна аргументация почему мы принимаем или отклоняем то или иное решение. Также мы используем оптику системного подхода, разбираемся как ии думает, что влияет на процесс в лучшую сторону \ в худшую сторону , что является полезным экстрактом поверх системных инстукрций и движка модели . Слабым моделям нужно больше подробных декларативных команд, сильным моделям такое может мешать (но не клоду), то есть получается взаимоисключающая задача. Под все модели получить равноценный универсальный результат поэтому корректно ориентироваться на флагманские fable \ sol.

В свежей статье OpenAI про их собственную agent-first разработку они описывают похожий опыт: большой AGENTS.md начинает вытеснять релевантный task/code context, модель оптимизируется под лишние ограничения.

При этом основной полезный пласт конвенций из #3 здесь не выбрасывается. В основном меняется организация контекста; отдельно убраны явно спорные универсальные правила типа no foreign keys.

Основная схема такая:

• AGENTS.md содержит небольшой общий контекст, устойчивые условия и маршрутизацию. Подробные правила лежат отдельно в references/ и читаются только если относятся к текущей задаче. Также отвечает на вопрос Будет ли модель регулярно делать неверный выбор без этой строки, и действительно ли правильный выбор одинаков во всех моих репозиториях?
• для интеграций подключается один provider-adapter skill. Его задача — понять конкретный flow, собрать нужный контекст и подгрузить только необходимые references;
• synchronous / callback / redirect / polling и т. д. — это не отдельные агенты и не обязательно отдельные правила. Skill определяет тип flow и уже по нему решает, какие материалы нужны;
• текущий src код является основной спецификацией локальной архитектуры. Если в проекте уже есть рабочий аналог, он важнее общей абстрактной конвенции;
• то, что можно сделать детерминированно, например ktlint format/check, делается tooling'ом без участия модели.

В итоге получается расширяемая схема: можно накапливать опыт и добавлять новые domain-specific guidance, но он не становится автоматически частью prompt для каждой задачи.

Вот эти моменты в дальнешем есть возможность перевести с ИИ управления на детерминированные скрипты без ии

• Protobuf compatibility
• OpenAPI validation
• generated sources consistency
• migration checks

[stdevman91]

Распиши плз, че зачем этот PR, что дает?