From 2c9d163d396e7a770bfa0be33bf7fd5e1c2860aa Mon Sep 17 00:00:00 2001 From: Sergey Krylov Date: Thu, 27 Aug 2026 15:24:56 +0300 Subject: [PATCH] docs(specs): drop archived optimize change --- .../.openspec.yaml | 7 - .../optimize-agent-token-workflow/design.md | 212 ------------------ .../optimize-agent-token-workflow/proposal.md | 60 ----- .../engineering-change-governance/spec.md | 66 ------ .../openspec-authority-and-lifecycle/spec.md | 54 ----- .../optimize-agent-token-workflow/tasks.md | 38 ---- 6 files changed, 437 deletions(-) delete mode 100644 openspec/changes/optimize-agent-token-workflow/.openspec.yaml delete mode 100644 openspec/changes/optimize-agent-token-workflow/design.md delete mode 100644 openspec/changes/optimize-agent-token-workflow/proposal.md delete mode 100644 openspec/changes/optimize-agent-token-workflow/specs/engineering-change-governance/spec.md delete mode 100644 openspec/changes/optimize-agent-token-workflow/specs/openspec-authority-and-lifecycle/spec.md delete mode 100644 openspec/changes/optimize-agent-token-workflow/tasks.md diff --git a/openspec/changes/optimize-agent-token-workflow/.openspec.yaml b/openspec/changes/optimize-agent-token-workflow/.openspec.yaml deleted file mode 100644 index dd341e4..0000000 --- a/openspec/changes/optimize-agent-token-workflow/.openspec.yaml +++ /dev/null @@ -1,7 +0,0 @@ -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 diff --git a/openspec/changes/optimize-agent-token-workflow/design.md b/openspec/changes/optimize-agent-token-workflow/design.md deleted file mode 100644 index f9e0160..0000000 --- a/openspec/changes/optimize-agent-token-workflow/design.md +++ /dev/null @@ -1,212 +0,0 @@ -## 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 | diff --git a/openspec/changes/optimize-agent-token-workflow/proposal.md b/openspec/changes/optimize-agent-token-workflow/proposal.md deleted file mode 100644 index b208d44..0000000 --- a/openspec/changes/optimize-agent-token-workflow/proposal.md +++ /dev/null @@ -1,60 +0,0 @@ -## 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. diff --git a/openspec/changes/optimize-agent-token-workflow/specs/engineering-change-governance/spec.md b/openspec/changes/optimize-agent-token-workflow/specs/engineering-change-governance/spec.md deleted file mode 100644 index 27a12ce..0000000 --- a/openspec/changes/optimize-agent-token-workflow/specs/engineering-change-governance/spec.md +++ /dev/null @@ -1,66 +0,0 @@ -## 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 diff --git a/openspec/changes/optimize-agent-token-workflow/specs/openspec-authority-and-lifecycle/spec.md b/openspec/changes/optimize-agent-token-workflow/specs/openspec-authority-and-lifecycle/spec.md deleted file mode 100644 index 418d403..0000000 --- a/openspec/changes/optimize-agent-token-workflow/specs/openspec-authority-and-lifecycle/spec.md +++ /dev/null @@ -1,54 +0,0 @@ -## 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 diff --git a/openspec/changes/optimize-agent-token-workflow/tasks.md b/openspec/changes/optimize-agent-token-workflow/tasks.md deleted file mode 100644 index 7533d20..0000000 --- a/openspec/changes/optimize-agent-token-workflow/tasks.md +++ /dev/null @@ -1,38 +0,0 @@ -## 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.