## 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.