docs(specs): start token-efficient agent pilot

2026-08-26 16:43:52 +03:00
parent 9a8687feda
commit 0b48b50f4a
7 changed files with 443 additions and 0 deletions
@@ -20,6 +20,12 @@ Proposal, Delta Specs, Design, Tasks, changes и archives хранятся в `o
 одному после approval Change Owner. Lifecycle:
 [`../docs/development/openspec-authority-and-lifecycle.md`](../docs/development/openspec-authority-and-lifecycle.md).

+Сначала определить current stage и capability paths через native OpenSpec
+instruction; читать main specs и supporting docs только для этих paths и
+affected areas. Подробный token-efficient routing загружается по необходимости
+из [`../docs/development/agent-token-efficiency.md`](../docs/development/agent-token-efficiency.md),
+а не дублируется в schema instructions.
+
 Из workspace canonical pre-archive gate:

 ```bash
@@ -0,0 +1,7 @@
+schema: wealth-ledger-sdd
+created: 2026-08-26
+goal: Reduce cumulative agent context usage without weakening WealthLedger SDD,
+  approvals, verification, or review quality.
+affected_areas:
+  - specs
+  - docs
@@ -0,0 +1,212 @@
+## Context
+
+WealthLedger уже разделяет нормативные change artifacts, durable engineering
+policy и компактные agent entrypoints, но root routing сейчас безусловно требует
+несколько широких документов до определения стадии и affected areas. В длинных
+сессиях широкие reads, verbose command results и последовательные независимые
+tool calls накапливаются в conversation history и повторно передаются каждому
+следующему model call. При этом OpenSpec уже предоставляет естественные
+checkpoint: каждый planning artifact создаётся отдельно, проходит structural
+gate и требует явного approval.
+
+Изменение должно использовать эти существующие boundaries, не создавать второй
+context map, не переносить normative policy в session summary и не превращать
+нестабильные показатели локальных rollout logs в completion gate. Workspace root
+не является Git-репозиторием, поэтому compact root routing обновляется локально,
+а versioned authority и as-built описание принадлежат `specs` и `docs`.
+
+## Goals / Non-Goals
+
+**Goals:**
+
+- сделать approved artifact естественной границей новой agent-сессии;
+- заменить blanket documentation reads на stage- и area-aware routing с явными
+  условиями обязательного on-demand чтения;
+- уменьшить избегаемые model/tool round-trips и объём переносимых успешных logs,
+  не теряя evidence для диагностики, verification и review;
+- провести ограниченный pilot на 10 post-change SDD-фазах и оценить resource
+  usage вместе с качеством результата;
+- сохранить рекомендации guidance до отдельного evidence-backed решения о hard
+  guardrail.
+
+**Non-Goals:**
+
+- менять artifact graph, approvals, canonical gates, semantic verification или
+  independent review;
+- внедрять telemetry proxy, новый session-log parser, внешнюю интеграцию либо
+  обязательную зависимость;
+- автоматически создавать, закрывать или переносить Codex tasks;
+- оптимизировать системный prompt, model selection, pricing или provider quota;
+- гарантировать одинаковый расход для несопоставимых по сложности фаз;
+- продвигать numeric token budget в completion blocker в рамках этого change.
+
+## Decisions
+
+### Durable policy, lazy playbook и compact routing имеют разных владельцев
+
+Canonical Specs сохраняют только наблюдаемые инварианты: stage-scoped context,
+approval-preserving handoff, сохранность evidence и совместную оценку ресурса с
+качеством. Engineering governance фиксирует устойчивое различие guidance и hard
+guardrail. Отдельный development playbook описывает операционные приёмы и pilot
+protocol; он загружается только для agent workflow work или при диагностике
+расхода. Root `AGENTS.md` остаётся коротким router: сначала stage и affected
+areas, затем conditional pointers к governance, architecture, glossary и audit
+material. Repository-local entrypoints сохраняют canonical gates и boundaries.
+
+Такое разделение предотвращает повторение подробного playbook в каждом agent
+prefix. Альтернатива — поместить все правила batching и budgets прямо в root
+`AGENTS.md` — отклонена, потому что увеличивает обязательный context каждой
+сессии и смешивает routing с объясняющей policy. Полностью удалить pointers тоже
+нельзя: agent должен иметь однозначный путь к authority при появлении
+релевантного вопроса.
+
+### Canonical artifact является handoff interface, но не доказательством approval
+
+После явного approval Proposal, Delta Specs, Design или Tasks следующая фаза
+может начинаться в новой Codex task. Минимальный handoff state содержит change
+identity, последний явно approved artifact, текущую фазу, affected areas,
+unresolved blockers и следующий разрешённый outcome. Planning content не
+копируется: новая task получает его из canonical OpenSpec store. Для перехода
+Apply → independent verification дополнительно передаётся фактический scope
+изменений и доступное evidence.
+
+Handoff остаётся сообщением пользователя или conversation state, а не новым
+versioned файлом. Наличие artifact без доступного явного approval не позволяет
+переходить дальше: агент повторно запрашивает решение Change Owner. Это сохраняет
+существующий approval contract и устраняет соблазн использовать summary как
+параллельный authority.
+
+Альтернатива — продолжать весь lifecycle в одной task и полагаться только на
+automatic compaction — отклонена: compaction наступает после накопления затрат и
+не совпадает с semantic boundaries SDD. Обязательная новая task после любого
+короткого действия также отклонена: стартовый context может быть дороже
+продолжения; boundary применяется после завершённого artifact или другого
+наблюдаемого milestone.
+
+### Evidence batching происходит только до следующего смыслового решения
+
+Agent сначала формирует bounded evidence set. Независимые read-only lookups,
+status checks и scoped source reads получают одним batch, если ни один результат
+не определяет следующий вызов. Discovery начинается с поиска identity или
+символа, затем читает найденные ranges. Diff discovery начинается с scope и
+paths, затем раскрывает relevant content. Успешный command result сохраняет
+command identity, exit status и существенную summary; verbose output не
+переносится полностью, если он не нужен следующему решению.
+
+Dependent calls, side effects, approval boundaries и semantic judgment остаются
+последовательными. Failure или неоднозначная summary расширяет diagnostics;
+canonical verification и reviewer получают весь relevant evidence. Soft output
+budgets помогают выбрать форму результата, но никогда не обрезают единственный
+диагностический сигнал.
+
+Альтернатива — blanket limit на строки или tool tokens — отклонена: статический
+cap может скрыть причину failure или material diff. Альтернатива всегда сохранять
+полный output — отклонена из-за доказанного накопления нерелевантного context.
+
+### Pilot измеряет фазу, resource usage и delivery quality совместно
+
+Immutable snapshot текущего session audit сохраняет baseline и его ограничения.
+После активации guidance pilot собирает 10 завершённых SDD-фаз как минимум из
+двух changes. Для каждого наблюдения фиксируются phase type, workload scope,
+cumulative input, model calls, context-depth indicators, tool-output volume,
+canonical-gate outcome, fix cycles и review findings. Незавершённые или
+прерванные попытки не включаются в denominator completed-phase efficiency, но
+учитываются отдельно как outcome, чтобы экономия не достигалась отбрасыванием
+неудач.
+
+Сравнение выполняется внутри одинаковых phase types и близкого scope, когда это
+возможно; общий aggregate сопровождается caveat о неоднородности задач. Успехом
+считается направленное уменьшение resource usage без ухудшения gate success,
+rework и findings. Результат pilot может подтвердить guidance, потребовать её
+пересмотра или дать основание для отдельного Proposal о детерминированном
+guardrail. Текущий change не повышает threshold автоматически.
+
+Change остаётся active до накопления и оценки 10 post-change фаз. Это увеличивает
+его календарную длительность, но позволяет завершить change с наблюдаемым
+результатом вместо предположения. Другие changes могут выполняться во время
+окна наблюдения и становятся источником pilot data.
+
+### Measurement не вводит новый runtime или parser
+
+Pilot использует provider-counted usage и существующую процедуру анализа rollout
+sessions. Raw rollout data не коммитится; versioned docs получают только
+агрегированные показатели, scope, метод и caveats. Любая стоимость или quota
+интерпретация отделяется от token counts и не объявляется причинно доказанной без
+provider contract.
+
+## Delivery Map
+
+| Area | Status | Architectural outcome or N/A reason |
+| --- | --- | --- |
+| frontend | `N/A` | Application behavior, frontend agent routing и canonical frontend gate не меняются. |
+| backend | `N/A` | Backend behavior, data, API contract, backend agent routing и canonical backend gate не меняются. |
+| specs | `affected` | Canonical lifecycle и engineering-governance requirements получают token-efficient context, handoff, evidence и pilot invariants; change проходит существующий planning lifecycle и sync. |
+| docs | `affected` | Durable engineering policy, lifecycle documentation, lazy operational playbook, development index, immutable baseline snapshot и pilot result описывают фактически активированный workflow без копирования planning artifacts. |
+
+Workspace root routing обновляется локально как orchestration outcome и не
+получает фиктивный repository commit.
+
+### Contract Gate Decision
+
+| Gate | Status | Reason |
+| --- | --- | --- |
+| runtime-openapi | `N/A` | Ни frontend, ни backend, ни публичный API contract не изменяются. |
+
+## Solution Assessment
+
+| Option | Fit and maturity | Security / operating cost | Constraints / migration cost | Decision |
+| --- | --- | --- | --- | --- |
+| Existing provider rollout usage plus project audit protocol | Уже доступные фактические session counters; достаточно для ограниченного pilot | Нет нового data path или runtime dependency; ручная классификация требует дисциплины | Формат usage может меняться, поэтому метод и caveats фиксируются вместе с результатом | Выбрано для pilot |
+| Project-owned rollout parser and token gate | Может автоматизировать повторный отчёт | Создаёт shared observability tooling и maintenance burden вокруг private/unstable local format | Потребует fixtures, compatibility policy и ложится в обязательный local workflow до доказанной ценности | Отклонено до повторяемой потребности |
+| External telemetry proxy or agent-cost platform | Зрелые варианты дают dashboards и cross-provider attribution | Меняет execution/data boundary, требует подключения, конфигурации и постоянной эксплуатации | Избыточно для локального pet-project pilot и не решает orchestration само по себе | Отклонено |
+| Только субъективная оценка скорости работы | Нулевая стоимость внедрения | Не создаёт privacy или runtime риска | Не позволяет отличить реальное улучшение от ощущения и не выполняет утверждённые Specs | Отклонено |
+
+Выбранный вариант переиспользует существующие данные и не создаёт custom
+observability subsystem. Trigger повторной оценки tooling: не менее двух
+последовательных pilot cycles требуют одинаковой ручной обработки либо native
+usage перестаёт давать необходимые counters.
+
+## Risks / Trade-offs
+
+- **Lazy context может скрыть обязательную authority.** Root routing сохраняет
+  явные triggers для domain, architecture, audit и gate questions; при появлении
+  такого вопроса relevant authority загружается до решения.
+- **Batch может объединить зависимые действия.** Guidance ограничивает batching
+  заранее независимыми read-only calls; side effects и adaptive discovery
+  остаются последовательными.
+- **Compact output может скрыть failure.** Любой non-zero или неоднозначный
+  result расширяет diagnostics, а review сохраняет full relevant scope.
+- **Новая task может потерять approval.** Handoff требует явного owner decision;
+  при отсутствии подтверждения workflow повторно запрашивает approval.
+- **Фазы различаются по сложности.** Pilot сохраняет phase type и scope,
+  сравнивает близкие наблюдения и публикует ограничения aggregate.
+- **Долгий pilot задерживает archive.** Guidance начинает действовать до archive,
+  а фиксированное окно 10 фаз ограничивает длительность и предотвращает
+  бессрочное наблюдение.
+- **Метрики могут стимулировать сокращение качества.** Gate outcomes, fix cycles,
+  interrupted attempts и review findings имеют равный статус с token usage.
+
+## Migration Plan
+
+1. Синхронизировать durable policy, lifecycle description и lazy operational
+   playbook с утверждёнными Specs; сохранить immutable baseline и measurement
+   protocol без raw session data.
+2. Перевести root routing с blanket reads на stage/area-first conditional
+   pointers, сохранив existing authority, SDD approvals и canonical gates.
+3. Активировать guidance для последующих agent phases и начать фиксированное
+   окно из 10 наблюдений минимум по двум changes.
+4. Сопоставить resource и quality outcomes, документировать ограничения и не
+   продвигать numeric threshold автоматически.
+5. После завершения pilot выполнить affected-area gates, semantic verification,
+   independent review и обычный sync/archive lifecycle.
+
+### Rollback Contract
+
+| Field | Decision |
+| --- | --- |
+| Status | `N/A` |
+| Reason | Изменение затрагивает обратимые instructions и документацию, не меняет auth/security behavior, данные, migration или public contract; откат выполняется обычным revert affected commits и восстановлением предыдущего локального root routing. |
+| Trigger | N/A |
+| Actions | N/A |
+| Data safety | N/A — пользовательские и runtime данные не создаются и не изменяются. |
+| Verification | N/A |
@@ -0,0 +1,60 @@
+## Why
+
+Недавний аудит Codex-сессий показал, что основной расход лимитов WealthLedger
+создаёт не генерация кода и не обязательные SDD-артефакты, а большое количество
+последовательных model/tool циклов на уже разросшемся контексте. Полное чтение
+нерелевантных документов, повторные широкие diff и logs, а также продолжение
+нескольких SDD-фаз в одной длинной сессии многократно переносят накопленный
+контекст без соразмерного прироста качества. Это повышает риск преждевременной
+компакции и исчерпания лимита именно в поздних фазах реализации и проверки.
+
+Процессу нужна измеримая token-efficient discipline, которая уменьшает
+повторную передачу контекста, но сохраняет существующие authority, approval
+gates, semantic verification и независимый review.
+
+## What Changes
+
+- Установить фазовые границы agent-сессий вокруг утверждённых SDD-артефактов,
+  чтобы следующая фаза продолжалась из canonical artifacts и явного решения
+  Change Owner, а не из полной истории обсуждения.
+- Сделать загрузку проектного контекста целевой: сначала определять текущую
+  стадию и affected areas, затем читать только применимые authority и
+  релевантные диапазоны материалов.
+- Сократить model/tool round-trips за счёт совместного получения независимых
+  evidence и компактного представления успешных command results, сохраняя
+  доступ к необходимым diagnostics при ошибке или семантической проверке.
+- Провести pilot и сравнивать расход контекста на успешно завершённую SDD-фазу
+  вместе с качественными ограничителями: результатами canonical gates,
+  количеством циклов исправления и findings независимого review.
+- Считать числовые budgets и пороги guidance до появления репрезентативных
+  данных и детерминированной локальной проверки; pilot не вводит новый hard
+  guardrail и не блокирует корректную работу только по объёму токенов.
+
+Не входят в change: удаление или объединение SDD-стадий, ослабление owner
+approvals, semantic verification, canonical gates или independent review;
+создание параллельного handoff/planning artifact; изменение пользовательского
+поведения frontend или backend; управление тарифами, quota, моделями или
+системным контекстом Codex; запрет tools или subagents как класса; немедленное
+введение обязательного token cap без результатов pilot.
+
+## Capabilities
+
+### New Capabilities
+
+Нет.
+
+### Modified Capabilities
+
+- `openspec-authority-and-lifecycle`: сделать переход между SDD-фазами и
+  загрузку agent context целевыми, сохраняя canonical artifacts и явные
+  approval gates единственным основанием продолжения работы.
+- `engineering-change-governance`: определить измеримую token-efficient
+  guidance и условия, при которых будущая рекомендация может стать
+  проверяемым hard guardrail без снижения качества поставки.
+
+## Impact
+
+Изменение затрагивает Engineering Owner и AI-агентов, которые планируют,
+реализуют и проверяют WealthLedger changes. Оно меняет нормативный SDD workflow,
+agent routing и as-built process documentation, но не изменяет frontend,
+backend, пользовательское поведение, данные или runtime API contracts.
@@ -0,0 +1,66 @@
+## ADDED Requirements
+
+### Requirement: Token-efficient execution сохраняет delivery evidence
+
+Project-owned agent guidance SHALL направлять AI-агента к совместному получению
+независимых read-only evidence, targeted чтению найденных диапазонов, сужению
+diff по затронутым paths и компактному представлению успешных command results.
+Такая оптимизация MUST сохранять exit status, существенный observed outcome и
+всё evidence, необходимое для текущего решения, canonical gate, semantic
+verification или independent review. При failure, неоднозначности или
+существенном расхождении workflow SHALL расширить diagnostics соразмерно
+наблюдаемой проблеме. Предпочтения по batching и размеру output SHALL оставаться
+guidance и MUST NOT блокировать корректную delivery без отдельного
+детерминированного hard guardrail.
+
+#### Scenario: Требуются несколько независимых read-only результатов
+
+- **WHEN** агент до следующего смыслового решения заранее знает несколько независимых source, status или diff запросов
+- **THEN** workflow направляет получить их одним evidence batch и вернуть только релевантные результаты без промежуточного model round-trip после каждого запроса
+
+#### Scenario: Canonical gate проходит успешно
+
+- **WHEN** обязательная verification command завершается успешно и её полный output не нужен для последующего смыслового решения
+- **THEN** agent context сохраняет точную command identity, exit status и существенную итоговую summary без обязательного переноса полного verbose log
+
+#### Scenario: Verification завершается ошибкой
+
+- **WHEN** compact command result сообщает failure или не позволяет определить причину
+- **THEN** workflow получает достаточные diagnostics для локализации ошибки и не скрывает необходимые failure details ради соблюдения output budget
+
+#### Scenario: Independent review требует полный relevant diff
+
+- **WHEN** reviewer должен проверить весь фактический scope реализации против утверждённых artifacts
+- **THEN** token-efficient guidance не исключает relevant diff или evidence, необходимые для semantic conclusion
+
+### Requirement: Token-efficiency оценивается на завершённых фазах вместе с качеством
+
+Token-efficiency pilot SHALL сравнивать resource usage на успешно завершённую
+SDD-фазу, включая cumulative input, количество model calls, глубину контекста и
+объём tool outputs, вместе с outcome indicators: результатами обязательных
+gates, количеством циклов исправления и findings independent review. Снижение
+resource usage MUST NOT считаться улучшением, если сопоставимая работа чаще не
+завершается, требует больше исправлений либо ухудшает verification или review
+outcomes. До накопления репрезентативных сопоставимых наблюдений числовые budgets
+SHALL оставаться guidance и MUST NOT становиться самостоятельным completion
+blocker.
+
+#### Scenario: Resource usage снизился без ухудшения результата
+
+- **WHEN** pilot показывает меньше cumulative input или model calls на сопоставимую завершённую фазу, а canonical gates, fix cycles и review findings не ухудшились
+- **THEN** изменение может быть представлено Engineering Owner как наблюдаемое улучшение с указанным measurement scope и ограничениями
+
+#### Scenario: Дешёвая фаза создаёт больше rework
+
+- **WHEN** вариант workflow использует меньше токенов, но чаще получает failed gates, дополнительные fix cycles или более серьёзные review findings
+- **THEN** pilot не представляет этот вариант как token-efficiency improvement
+
+#### Scenario: Наблюдений недостаточно для обязательного порога
+
+- **WHEN** pilot ещё не содержит репрезентативных сопоставимых завершённых фаз или надёжной локальной проверки
+- **THEN** model-call, context-depth и tool-output budgets остаются guidance и не блокируют delivery
+
+#### Scenario: Числовой budget предлагается как hard guardrail
+
+- **WHEN** последующий change предлагает сделать token budget обязательным completion condition
+- **THEN** он должен определить защищаемый риск, детерминированную non-mutating проверку и controlled compliant/violation evidence по общему contract Enforceable Engineering Invariant
@@ -0,0 +1,54 @@
+## ADDED Requirements
+
+### Requirement: Agent context следует текущей SDD-фазе
+
+Project-owned agent workflow SHALL начинать каждую работу с определения текущей
+SDD-фазы и affected delivery areas, а затем SHALL загружать canonical artifacts,
+локальные routing instructions и supporting authority, применимые к этой фазе и
+этим areas. Переход в новую agent-сессию после утверждения planning artifact
+SHALL использовать canonical artifact и явное решение Change Owner как основание
+продолжения. Workflow MUST NOT требовать полную историю предыдущей сессии или
+отдельный handoff/context artifact, дублирующий OpenSpec authority. Supporting
+material, не влияющий на текущую фазу, затронутую область, доменную семантику или
+обязательный gate, SHALL загружаться только при появлении наблюдаемой
+необходимости.
+
+#### Scenario: Утверждённый artifact передаётся в новую сессию
+
+- **WHEN** Change Owner явно утверждает текущий planning artifact и следующая agent-сессия продолжает change на разрешённой downstream-фазе
+- **THEN** workflow восстанавливает работу из canonical change artifacts, owner approval и применимых routing instructions без обязательной передачи полной истории обсуждения или создания второго handoff artifact
+
+#### Scenario: Работа ограничена одной delivery area
+
+- **WHEN** текущая фаза затрагивает одну определённую delivery area и не требует cross-system или доменной оценки
+- **THEN** workflow загружает authority и локальные instructions этой area, а нерелевантные architecture, domain и repository materials остаются lazy context
+
+#### Scenario: Supporting material становится необходимым
+
+- **WHEN** во время работы возникает вопрос, влияющий на domain semantics, cross-area architecture, audit disposition или обязательный gate
+- **THEN** workflow загружает соответствующий authoritative material до принятия решения и не использует token-efficiency guidance как основание пропустить требуемый контекст
+
+### Requirement: Session handoff сохраняет approval boundary
+
+Разделение agent-сессий SHALL происходить только на наблюдаемой границе, где
+завершённый результат представлен canonical artifact, применённым изменением или
+verification outcome. Handoff SHALL сохранять change identity, последний явно
+утверждённый artifact, текущую фазу, affected areas, unresolved blockers и
+следующий разрешённый outcome. Если новая сессия не имеет явного подтверждения
+approval, workflow MUST повторно запросить решение Change Owner и MUST NOT
+выводить approval только из наличия artifact.
+
+#### Scenario: Planning-фаза завершилась approval
+
+- **WHEN** Change Owner утвердил Proposal, Delta Specs или Design и работа продолжается в новой сессии
+- **THEN** handoff указывает change identity, утверждённую границу и единственный следующий разрешённый artifact, не перенося нерелевантную историю инструментов и обсуждений
+
+#### Scenario: Approval невозможно подтвердить
+
+- **WHEN** canonical artifact существует, но доступный контекст новой сессии не содержит явного решения Change Owner
+- **THEN** workflow останавливается перед downstream artifact и повторно запрашивает approval
+
+#### Scenario: Реализация переходит к независимой проверке
+
+- **WHEN** Apply завершил заявленную работу и change передаётся в свежий verification/review context
+- **THEN** handoff сохраняет approved artifacts, affected areas, фактический implementation scope и unresolved blockers, а reviewer получает необходимый diff и evidence без полной implementation history
@@ -0,0 +1,38 @@
+## 1. Policy, routing и baseline
+
+- [x] 1.1 [docs] Сохранить исходный session-token audit как immutable dated snapshot, добавить его в audits index и создать lazy development playbook с routing matrix, handoff envelope, evidence-batching boundaries, failure expansion и pilot protocol без копирования OpenSpec artifacts
+  - **Covers:** `openspec-authority-and-lifecycle` — `Agent context следует текущей SDD-фазе`; `openspec-authority-and-lifecycle` — `Session handoff сохраняет approval boundary`; `engineering-change-governance` — `Token-efficient execution сохраняет delivery evidence`; `engineering-change-governance` — `Token-efficiency оценивается на завершённых фазах вместе с качеством`
+  - **Verification:** Сверить source/snapshot checksum и byte count, затем выполнить scoped review playbook против всех четырёх Requirements и проверить links обоих indexes.
+- [x] 1.2 [docs] Обновить engineering governance и OpenSpec lifecycle documentation до durable policy stage/area-first context, explicit approval handoff, guidance-only output budgets и quality-coupled pilot, оставив подробные операции в lazy playbook
+  - **Covers:** `openspec-authority-and-lifecycle` — `Agent context следует текущей SDD-фазе`; `openspec-authority-and-lifecycle` — `Session handoff сохраняет approval boundary`; `engineering-change-governance` — `Token-efficient execution сохраняет delivery evidence`; `engineering-change-governance` — `Token-efficiency оценивается на завершённых фазах вместе с качеством`
+  - **Verification:** Провести read-only ownership review updated policy, lifecycle и playbook и подтвердить одно authoritative место для каждого правила без blanket duplication.
+- [x] 1.3 [specs] Сделать specs-local agent routing stage-scoped и compact, сохранив fixed store, one-artifact approvals, current-stage instructions и conditional pointer к lazy playbook без встраивания подробного token guidance в каждый schema artifact
+  - **Covers:** `openspec-authority-and-lifecycle` — `Agent context следует текущей SDD-фазе`; `openspec-authority-and-lifecycle` — `Session handoff сохраняет approval boundary`
+  - **Verification:** Получить instructions Proposal, Specs, Design, Tasks и Apply из project schema, затем подтвердить current-stage authority, approval boundary, fixed store и отсутствие повторённого full playbook в prefix inputs.
+- [x] 1.4 [workspace] Заменить root blanket reads на compact stage/affected-area-first routing и conditional triggers для governance, architecture, domain и audit material, добавив короткий handoff и evidence-batching pointer без создания versioned workspace artifact
+  - **Covers:** `N/A` — workspace root routing оркестрирует применение repository-owned policy и не является самостоятельным behavior contract или repository implementation.
+  - **Verification:** На read-only routing matrix для scoped repository work, cross-area architecture, domain semantics, audit-derived work и failed verification подтвердить минимальный initial context и обязательную загрузку каждого relevant authority trigger.
+
+## 2. Pilot observation и verdict
+
+- [ ] 2.1 [workspace] Активировать approved guidance и собрать local non-authority dataset для 10 последующих завершённых SDD-фаз минимум по двум changes, отдельно учитывая interrupted attempts, phase/scope, input, model calls, context depth, tool output, gate outcome, fix cycles и review findings
+  - **Covers:** `N/A` — workspace task собирает observation inputs для docs-owned pilot verdict и не подменяет repository-owned implementation Requirements.
+  - **Verification:** Проверить 10 completed observations минимум для двух change identities, наличие всех resource/quality fields, отдельный перечень interrupted attempts и отсутствие raw rollout content в Git.
+- [ ] 2.2 [docs] Опубликовать агрегированный pilot result с method, scope, comparable phase groups, resource и quality outcomes, confounders и verdict; обновить guidance только в пределах наблюдаемых данных и не продвигать numeric budget в hard guardrail
+  - **Covers:** `engineering-change-governance` — `Token-efficiency оценивается на завершённых фазах вместе с качеством`
+  - **Verification:** Пересчитать агрегаты из local pilot dataset, сопоставить verdict с gate/fix/review outcomes и проверить отсутствие unsupported quota, cost или causal claims.
+
+## 3. Affected-area gates и итоговая проверка
+
+- [ ] 3.1 [specs] Выполнить canonical specs checks для compact routing и полного planning change после завершения pilot
+  - **Covers:** `N/A` — задача проверяет specs delivery уже покрытых lifecycle Requirements и не вводит самостоятельное observable behavior.
+  - **Verification:** Запустить OpenSpec version preflight, schema validation, planning verifier, strict change validation, strict main-spec validation, authority verifier и `git diff --check` в `specs`.
+- [ ] 3.2 [docs] Выполнить canonical docs gate и scoped проверку baseline snapshot, development indexes, policy/playbook links и pilot result
+  - **Covers:** `N/A` — задача проверяет docs delivery уже покрытых Requirements и не создаёт новый behavior contract.
+  - **Verification:** Запустить `npm run verify` в `docs`, подтвердить affected local links и повторно сверить immutable baseline checksum.
+- [ ] 3.3 [workspace] Выполнить canonical cross-area dispatcher с Delivery Map `specs/docs=affected`, `frontend/backend=N/A` и Contract Gate `runtime-openapi=N/A`
+  - **Covers:** `N/A` — workspace task оркестрирует affected-area gates и не подменяет repository-owned implementation.
+  - **Verification:** Запустить `bash specs/scripts/verify-workspace-change.sh optimize-agent-token-workflow` и проверить наблюдаемый выбор только утверждённых affected areas и gates.
+- [ ] 3.4 [workspace] Провести semantic verification реализации и pilot verdict против Proposal, всех 4 Delta Requirements, 14 Scenarios, Design и Tasks, затем independent read-only review без Critical или Important findings
+  - **Covers:** `N/A` — terminal semantic verification и independent review проверяют change целиком, но не реализуют отдельный Requirement.
+  - **Verification:** Зафиксировать observed coverage каждого Requirement/Scenario и устранить blocking findings до archive eligibility.