specs/openspec/changes/archive/2026-09-09-clarify-agent-context-routing/proposal.md

Why

Действующие инструкции не всегда однозначно показывают, какие локальные правила нужны для конкретного изменения и когда выбор контекста следует пересмотреть. Отдельные формулировки смешивают автоматическое блокирование с обязательным review или описывают прежнюю процедуру как актуальную. Это создаёт риск пропуска требований и неоправданной уверенности в успешных проверках.

Discovery завершена; первый этап согласован как уточнение существующих источников и перенос frontend-local conventions. Сейчас нужно закрепить границы этого этапа, сохранив действующие требования и lifecycle safeguards.

What Changes

• Сохранить один актуальный набор всех шести frontend-local документов в согласованной frontend/.ai/ вместо frontend/docs/, с компактным входом по типу изменения и работающей действующей навигацией. Общая engineering policy, architecture, ADR и as-built документация остаются у общего docs authority.
• Сделать выбор локального контекста однозначным для изменений структуры и импортов, компонентов и продуктовых строк, представления и восстановления состояний, взаимодействия с сервером, а также тестов и поведения с testing risk trigger. Несвязанная задача не требует чтения всех conventions.
• Закрепить в существующей context authority проверку маршрутизации до первого зависимого решения, при обнаружении новой области или границы и перед handoff по фактическому набору staged, unstaged и новых файлов. Расширение обнаруженного scope не разрешает выходить за approved planning boundaries.
• Сохранить обязательное получение всех native contextFiles, применимых risk inputs и согласованного Design package при работе и recovery независимо от количества документов. Фаза определяет нужный контекст; новый workflow или параллельный context map не возникает.
• Различать реально автоматизированные запреты, обязательные процедуры и semantic review, а также необязательное guidance. Исправление неточного обещания проверки не ослабляет обязательность локализации, правил валидации и остальных действующих требований. Рекомендации по тестированию соответствуют установленной инфраструктуре и используемым практикам.
• Обозначить исторический статус заменённых частей архитектурного решения и направить к текущей принятой процедуре с сохранением rationale и правил ведения ADR. Изменяемая информация о каталоге интерфейса принадлежит его документу-владельцу; workflow ссылается на него. Использование уже поставленного каталога не требует повторного согласования его добавления.
• Сохранить содержание всех переносимых требований к структуре и границам модулей, локализации и валидации, стилю компонентов с действующими исключениями, типизированному доступу к данным и авторизации, разделению данных и представления, состояниям и доступности интерфейса, восстановлению после ошибок и тестированию. Canonical gates, отдельные approvals, fingerprints, независимая Validation и Finalization сохраняются.

Ожидаемый результат — применимые правила доступны до зависящего от них решения, актуальные ссылки разрешаются, а перенос не оставляет двух поддерживаемых копий и не теряет требований. Это относится как к отдельной UI-, API- или testing-задаче, так и к расширению scope и recovery; неприменимые conventions остаются вне обязательного контекста несвязанной задачи.

Вне scope:

• Изменение runtime-поведения frontend/backend и массовый рефакторинг conventions.
• Восстановление bundle budget checker, разрешение связанного spec drift, восстановление backend e2e и переработка переносимости Completion Evidence.
• Новые instruction layers, реестры conventions, метаданные, context frameworks, CI, hooks, dispatchers, checker frameworks, telemetry или dependency packages.
• Scoring, числовой token gate или ограничение числа обязательных документов.
• Перенос всей документации проекта в локальные инструкции frontend.
• Переписывание historical archives, dated audit snapshots и старого Completion Evidence; их прежние пути сохраняют исторический контекст.
• Повторный аудит workspace и последующие этапы улучшения guardrails.

Capabilities

New Capabilities

Нет.

Modified Capabilities

• specs/openspec-authority-and-lifecycle/spec.md: уточнить обязательный выбор контекста по фазе и фактическому scope, моменты повторной проверки маршрутизации и применимость локальных conventions без пропуска обязательных inputs или обхода approval boundaries. Остальные действующие инварианты сохраняются.

Impact

Изменение затрагивает AI-агентов, разработчиков, Change Owner и независимых reviewers, которые планируют, выполняют и проверяют работу в workspace.

• frontend — расположение и маршрутизация локальных conventions, точность инструкций и действующая навигация; поведение приложения не меняется.
• docs — context discipline, актуальные workflow summaries, навигация и историческая квалификация заменённых частей ADR при сохранении общей authority.
• specs — canonical planning и уточнение существующего требования о выборе контекста; без дублирующего planning store и изменения исторических artifacts.
• backend — N/A: первый этап не меняет его поведение, контракт, реализацию, локальные инструкции или gate.

Согласование направления не является approval этого Proposal или downstream artifacts. Каждый следующий artifact и переход роли сохраняет отдельную границу canonical lifecycle.