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

1. Frontend-local conventions и входы

До первых delivery edits сохранить в рабочем контексте исходный inventory по context authority, включая staged/unstaged/new inputs и bytes защищённых historical paths для проверки 3.2. Новый versioned artifact для этого не нужен.

• 1.1 [frontend] Перенести все шесть документов из docs/ непосредственно в .ai/, сохранив одноимённых владельцев и содержание по таблице сохранения в Design; убрать прежний поддерживаемый набор без redirect stubs и второго registry.
  • Covers: openspec-authority-and-lifecycle — Frontend-local conventions имеют единый вход по содержанию изменения
  • Verification: Сопоставить исходные документы и перенос по каждой строке таблицы Design, включая FSD без widgets, i18n/validationMessage, React/Storybook exceptions, typed API/auth/refresh, VM/view, cached snapshot, skeleton accessibility, recovery и MSW/risk-based testing; проверить наличие только шести согласованных файлов непосредственно в .ai/ и отсутствие второй поддерживаемой копии в docs/.
• 1.2 [frontend] Сделать .ai/README.md компактным router с объединением triggers и ссылками на общие authorities; направить к нему AGENTS.md и README приложения, обновив их прямые ссылки на conventions и сохранив local gate и boundaries.
  • Covers: openspec-authority-and-lifecycle — Frontend-local conventions имеют единый вход по содержанию изменения
  • Verification: Проверить все пять маршрутов Design и сочетание нескольких triggers; проследить локальные входы до существующего target и применимого раздела, убедиться, что AGENTS/README не предписывают читать весь набор без triggers и не копируют общую policy.
• 1.3 [frontend] Уточнить обязательность и enforcement в AGENTS и перенесённых conventions; согласовать TESTING с используемым fireEvent и объявленными зависимостями, а описание Storybook — с уже поставленной инфраструктурой.
  • Covers: openspec-authority-and-lifecycle — Активные инструкции точно описывают обязательность и способ обеспечения правил
  • Verification: Сверить автоматические утверждения и исключения с текущим biome.json, а testing guidance — с package.json, lockfile и интерактивными тестами; проверить сохранение mandatory i18n/validationMessage и React review conventions, точное описание транзитивного user-event, доступность существующего каталога без повторного approval установки и отсутствие изменений dependencies, runtime или gate.

2. Общая context authority и текущая документация

• 2.1 [docs] Дополнить Routing context в development/agent-token-efficiency.md повторной сверкой до первого зависимого решения, при новой границе и перед handoff по staged/unstaged/new inputs; добавить короткие ссылки на эту процедуру в применимых фазах development/openspec-authority-and-lifecycle.md.
  • Covers: openspec-authority-and-lifecycle — Agent context следует текущей SDD-фазе
  • Verification: Проверить различие новой границы внутри approved scope и расширения intent/behavior/architecture/Tasks, полноту native contextFiles/risk inputs/Design package при recovery, reuse неизменившихся inputs и явный blocker при missing input; убедиться, что сохранены существующие fingerprints/approval boundaries и не созданы второй context map, workflow, scoring или лимит чтения.
• 2.2 [docs] Уточнить Guardrails в development/engineering-governance.md: отделить автоматические Enforceable Engineering Invariants от обязательных процедур/semantic review и необязательного guidance, согласовав общую policy с frontend instructions.
  • Covers: openspec-authority-and-lifecycle — Активные инструкции точно описывают обязательность и способ обеспечения правил
  • Verification: Сопоставить governance с результатом 1.3: отсутствие checker не снимает явно обязательное требование, существующее автоматическое блокирование сохраняет свой статус, эстетические предпочтения остаются guidance; проверить сохранение canonical gates, approvals, fingerprints, независимой Validation и отсутствия новых checkers.
• 2.3 [docs] Добавить ADR 011 adr/011-native-openspec-lifecycle-with-repository-gates.md о действующем native lifecycle и repo gates; обозначить частичную историческую замену ADR 010 и обновить ADR index, сохранив rationale и рассмотренные альтернативы.
  • Covers: openspec-authority-and-lifecycle — Активные инструкции точно описывают обязательность и способ обеспечения правил
  • Verification: Проверить соответствие adr/README.md, контекст/решение/последствия нового ADR, взаимные ссылки и указатели к текущим authorities; сверить формулировки schema v3/v5, прежних verifiers/dispatcher и сохранённого .cli-version с актуальными источниками, без изменения version contract, schema и untouched main requirements.
• 2.4 [docs] Обновить текущие ссылки на frontend conventions в UI-каталоге и remediation registry; убрать дублируемое число групп каталога из frontend workflow, оставив ссылку на development/ui-catalog.md как owner этих сведений.
  • Covers: openspec-authority-and-lifecycle — Frontend-local conventions имеют единый вход по содержанию изменения; openspec-authority-and-lifecycle — Активные инструкции точно описывают обязательность и способ обеспечения правил
  • Verification: Проверить targets и anchors изменённых ссылок после переноса; в registry сравнить diff только live адресов conventions/UI pattern, сохранив Audit IDs, dispositions, статусы, даты, findings и evidence links; проверить отсутствие второй числовой сводки в workflow и сохранение Design approval/Validation при использовании существующего Storybook.

3. Implementation-owned проверка согласованного поведения

• 3.1 [workspace] Пройти routing scenarios Delta Specs по итоговым instructions, проверяя выбор обязательного контекста и неприменимые контрпримеры без добавления тестов, повторяющих Markdown.
  • Covers: N/A — задача не вводит самостоятельного observable behavior; это необходимая cross-area проверка frontend router и общей context discipline по решению 8 Design перед передачей реализации в независимую Validation.
  • Verification: Для UI-only props/presentation проверить CONVENTIONS + UI-PATTERN без необоснованных API/STRUCTURE/TESTING; для auth/refresh — API-LAYER + TESTING и применимый contract/domain context; для изменения только тестов, slice/imports или строк — соответствующие triggers. Docs-only опечатка не должна требовать frontend conventions. Отдельно пройти первое решение без diff, supporting input по новой необходимости, новую границу внутри approved scope и расширение за его пределы, handoff с unstaged/new files, recovery полного обязательного пакета и missing-input blocker; сохранить observed outcomes в рабочем контексте без нового versioned registry или независимого verdict.
• 3.2 [workspace] Проверить межрепозиторную навигацию и границы документационного переноса по фактическому inventory, включая сохранение исторических inputs и отсутствие непредусмотренных изменений.
  • Covers: N/A — самостоятельное поведение не добавляется; согласованный перенос между независимыми репозиториями требует cross-area проверки ссылок и сохранения inputs по решениям 4 и 6 Design, которую один repository gate не покрывает.
  • Verification: Найти старые paths в действующих entrypoints и проверить все применимые targets/anchors, включая optional entrypoints при наличии совпадений; отличить historical references и generated graph/cache outputs от live navigation. Сравнить historical archives, dated audits, прежнее Completion Evidence и датированные research/browser snapshots с исходным inventory по bytes; по staged/unstaged/new scope проверить сохранение root/optional routing при отсутствии затронутых ссылок, неизменность runtime/dependencies/gates и соблюдение read-only references policy.

4. Repository-owned delivery и canonical gates

Нормативный deliverable specs — canonical change, подготовленный Specification. Design не предусматривает отдельную implementation-редакцию schema или main specs: задача 4.3 проверяет эту repository-owned поставку. Semantic sync остаётся на границе Finalization. Backend и runtime-openapi имеют N/A по Delivery Map. Независимая Validation не является checkbox этой реализации.

• 4.1 [frontend] Выполнить canonical frontend gate на итоговом frontend delivery после переноса и уточнения инструкций.
  • Covers: N/A — новое observable behavior не вводится; repository-owned проверка обязательна для affected frontend delivery по Delivery Map, хотя runtime и gate остаются прежними.
  • Verification: Из frontend выполнить nvm use --silent, lockfile install npm ci и npm run verify; сохранить exact commands, cwd, exit status, существенный observed output и relevant input inventory/fingerprint по context authority. Проверить, что tracked outputs не изменены самим non-mutating gate.
• 4.2 [docs] Выполнить canonical docs gate на итоговой policy, ADR и действующей навигации.
  • Covers: N/A — это необходимая repository-owned проверка affected docs delivery по Delivery Map, не отдельное spec-level поведение и не замена scoped link review из 2.4 и 3.2.
  • Verification: Из docs выполнить nvm use --silent, lockfile install npm ci и npm run verify; сохранить exact commands, cwd, exit status, существенный observed output и relevant input inventory/fingerprint по context authority, без запуска auto-fix как доказательства корректности.
• 4.3 [specs] Проверить полноту и целостность repository-owned canonical change на текущем native inventory и выполнить specs gate, сохраняя утверждённые planning inputs.
  • Covers: N/A — нормативное specs delivery уже выражено canonical artifacts этого change; задача обеспечивает его обязательную repository-owned structural проверку по Delivery Map без дополнительной мутации ради участия specs, нового поведения или переноса completion operations в Implementation.
  • Verification: Активировать frontend .nvmrc через nvm use --silent до перехода в specs; выполнить openspec status --change clarify-agent-context-routing --json --store wealth-ledger-specs, openspec schema validate wealth-ledger-sdd --verbose, openspec validate clarify-agent-context-routing --type change --strict --json --store wealth-ledger-specs и openspec validate --specs --strict --store wealth-ledger-specs. По native inventory сверить approval bindings с действующей нормализацией task progress; сохранить exact commands, cwd, exit status, существенный observed output и relevant input inventory/fingerprint. При изменённом planning input вернуть работу к ответственной boundary, не исправлять approved содержание неявно.