specs/openspec/specs/openspec-authority-and-lifecycle/spec.md

openspec-authority-and-lifecycle Specification

Purpose

Определяет единственный источник полномочий для OpenSpec и проверяемый жизненный цикл SDD-изменений независимо от текущей директории, глобальной конфигурации или agent framework.

Requirements

Requirement: SDD-артефакты имеют непересекающиеся полномочия

Proposal SHALL выражать причину, намерение, границы и ожидаемый эффект change языком владельца и MUST NOT содержать решения по технологиям, структуре кода, файлам, API или зависимостям. Delta Specs SHALL определять только добавленное, изменённое или удалённое наблюдаемое поведение и инварианты системы без описания изменений кода. Design SHALL объяснять архитектурный способ выполнения утверждённых Specs, существенные решения, риски и альтернативы крупными частями и MUST NOT становиться построчной инструкцией реализации. Применимые UI/UX-решения и визуальные материалы SHALL входить в единый canonical Design и MUST NOT образовывать отдельный planning authority или отдельный UI/UX approval. Tasks SHALL быть implementation checklist, достаточным для выполнения Design и Specs, и MUST NOT содержать ещё не наблюдённые completion results, commit identifiers или post-archive bookkeeping. Completion Evidence SHALL фиксироваться только после фактической реализации и верификации и MUST NOT подменять planning artifact. Концептуальные материалы и Discovery SHALL оставаться входным контекстом и MUST NOT считаться утверждёнными OpenSpec artifacts.

Scenario: Product Owner формулирует Proposal

• WHEN владелец описывает требуемое изменение, не зная структуры кода и файлов
• THEN Proposal остаётся полноценным утверждаемым намерением без необходимости принимать архитектурные решения

Scenario: Агент подготавливает Tasks

• WHEN Proposal, Delta Specs и Design уже утверждены
• THEN Tasks перечисляет конкретные действия реализации и проверки, но не заявляет будущие результаты уже выполненными

Scenario: Владелец согласует визуальный результат

• WHEN Change Owner явно утверждает Design с применимыми визуальными материалами
• THEN решение распространяется на обозначенную версию всего пакета Design в существующем approval gate без новой SDD-роли или отдельного UI/UX approval

Scenario: Концепт доступен до Design

• WHEN обсуждение или Discovery содержит визуальный концепт
• THEN его наличие не разрешает downstream planning или реализацию и не заменяет явное утверждение соответствующего OpenSpec artifact

Requirement: Artifact graph применяет последовательные approval gates

Versioned SDD change SHALL проходить последовательность Proposal → Delta Specs → Design → Tasks → Apply. AI-агент MAY подготовить черновик текущего разрешённого артефакта, но MUST NOT считать его утверждённым самостоятельно или создавать downstream artifact до явного решения Change Owner. Для change, определяющего продуктовое поведение, Change Owner SHALL быть Product Owner; для технического или процессного change — Engineering Owner. Каждый из четырёх planning artifacts MUST существовать и быть утверждён до Apply.

Scenario: Proposal ещё не утверждён

• WHEN AI-агент завершил черновик Proposal, но Change Owner не дал явного согласия
• THEN Delta Specs, Design и Tasks остаются недоступны для создания

Scenario: Delta Specs утверждены

• WHEN Change Owner явно подтверждает Delta Specs после утверждённого Proposal
• THEN Design становится следующим разрешённым planning artifact, а Tasks и Apply остаются заблокированы

Requirement: Изменение upstream artifact требует каскадной проверки

Изменение утверждённого Proposal MUST инициировать повторную проверку Delta Specs, Design и Tasks; изменение утверждённых Delta Specs MUST инициировать повторную проверку Design и Tasks; изменение утверждённого Design MUST инициировать повторную проверку Tasks. Изменение Tasks MUST NOT неявно менять scope, наблюдаемое поведение или архитектурные решения upstream artifacts; при таком обнаружении workflow SHALL вернуть работу к самому раннему затронутому upstream artifact и его approval gate. Если несоответствие обнаружено во время Design или Apply, downstream-работа MUST остановиться, а Change Owner MUST получить наблюдаемое основание возврата и решения, требуемые на выбранном уровне. Механическое исправление синтаксиса или формата, которое не меняет утверждённые намерение, поведение, архитектурные решения или состав задач, MUST пройти повторную structural validation и MUST NOT само по себе инвалидировать approvals. Исправление Markdown heading, опечатки без изменения нормативного смысла или выравнивания таблицы MAY считаться механическим; изменение формулировки Requirement, добавление или удаление Scenario, изменение выбранного архитектурного решения либо planned Verification задачи MUST NOT считаться механическим.

Scenario: После Design изменилось намерение

• WHEN владелец меняет scope или ожидаемый эффект Proposal
• THEN зависимые Delta Specs, Design и Tasks теряют прежнее подтверждение до повторной согласованной проверки

Scenario: Task вводит новое поведение

• WHEN implementation checklist требует поведение, которого нет в утверждённых Delta Specs
• THEN агент не расширяет scope через Tasks и возвращает change к Delta Specs

Scenario: Apply выявляет архитектурное расхождение

• WHEN во время реализации обнаружено, что утверждённый Design не позволяет выполнить Specs без другого архитектурного решения
• THEN Apply останавливается, Tasks теряет прежнее подтверждение, а change возвращается к Design с наблюдаемым основанием и вариантами решения

Scenario: Исправляется только структурный формат

• WHEN утверждённый artifact содержит исправимую синтаксическую или formatting-ошибку без изменения его смысла
• THEN workflow исправляет ошибку, повторяет structural validation и сохраняет действующие approvals

Scenario: Меняется planned Verification

• WHEN исправление Tasks меняет способ, которым должна подтверждаться поставка
• THEN workflow рассматривает изменение как semantic task-scope change и повторно запрашивает approval Tasks

Requirement: Канонический authority OpenSpec задан явно

WealthLedger SHALL использовать зарегистрированный store wealth-ledger-specs с физическим OpenSpec root specs/openspec как единственный поддерживаемый authority для versioned SDD artifacts. Каждый project-owned OpenSpec entrypoint и documented OpenSpec command MUST явно выбирать --store wealth-ledger-specs; он MUST NOT выбирать store из ближайшего root, текущей директории или глобального значения по умолчанию машины.

Scenario: Агент начинает SDD-работу из репозитория приложения

• WHEN агент начинает, продолжает, проверяет, синхронизирует или архивирует OpenSpec change из frontend, backend, docs или workspace root
• THEN documented workflow явно выбирает wealth-ledger-specs и разрешает artifacts под specs/openspec

Scenario: В окружении есть другой OpenSpec store или значение по умолчанию

• WHEN машина имеет другой зарегистрированный OpenSpec store или другое глобальное значение по умолчанию
• THEN project-owned entrypoints всё равно используют wealth-ledger-specs и не выполняют fallback к другому root

Requirement: Versioned planning artifacts имеют единственное допустимое расположение

Система SHALL хранить committed OpenSpec specifications, changes, designs, delta specifications, tasks и archives только под specs/openspec. Она MUST NOT создавать или коммитить framework-specific planning, specification, task или design artifacts вне этого расположения, включая superpowers/plans. Это ограничение MUST NOT изменять или удалять read-only material под references/**.

Scenario: Агент фиксирует функциональное изменение

• WHEN агенту нужно зафиксировать requirements, design decisions или implementation tasks для функционального change
• THEN он создаёт versioned SDD artifacts в canonical OpenSpec store и не создаёт parallel framework artifact вне него

Scenario: Агент изучает reference material

• WHEN агент встречает framework artifacts под references/**
• THEN он рассматривает их как read-only reference content и не классифицирует их как нарушение policy

Requirement: Authority policy имеет read-only verifier

Canonical store и policy расположения artifacts SHALL иметь documented read-only verifier. Verifier MUST возвращать ненулевой результат, когда project-owned OpenSpec entrypoint не выбирает canonical store, когда запрещённый project-owned planning artifact существует вне specs/openspec, или когда существует дополнительный project-owned openspec/ root; он MUST исключать references/** из проверок расположения artifacts.

Scenario: Canonical authority остаётся целостным

• WHEN verifier запускается в compliant workspace
• THEN он завершается без изменения tracked files и сообщает об успехе

Scenario: Entry point вновь допускает неявный выбор store

• WHEN project-owned OpenSpec entrypoint допускает выбор nearest-root или global-default
• THEN verifier завершается ошибкой и указывает non-compliant entrypoint

Requirement: OpenSpec tooling имеет проверяемый version contract

SDD workflow MUST объявлять одну текущую поддерживаемую версию OpenSpec CLI в canonical version contract и проверять фактическую версию до команд, читающих или изменяющих canonical change. Normative checks и проверяемые generated markers MUST получать ожидаемую версию из этого контракта и MUST NOT независимо закреплять конкретный version literal. Несовместимая либо неопределённая версия MUST давать actionable blocking result и MUST NOT приводить к молчаливому изменению artifact graph, templates или project-owned entrypoints. Публикация новой stable версии MUST NOT автоматически менять поддерживаемую версию проекта. Upgrade SHALL изменять version contract только после изолированной проверки совместимости schema, agent workflow, canonical store и hard blockers и SHALL сохранять историческое evidence с фактически использованными ранее версиями.

Scenario: Версия CLI соответствует контракту

• WHEN агент начинает работу с canonical change поддерживаемой версией OpenSpec
• THEN workflow продолжает работу с объявленной схемой и canonical store

Scenario: Версия CLI не соответствует контракту

• WHEN доступная версия OpenSpec не совпадает с объявленным совместимым контрактом
• THEN локальная preflight-проверка блокирует SDD-операцию и сообщает ожидаемую и фактическую версии

Scenario: Опубликована новая stable версия

• WHEN upstream публикует новую stable версию, которая ещё не прошла project compatibility assessment
• THEN текущий version contract остаётся действующим и новая версия не становится неявным требованием для разработки

Scenario: Подготовлен upgrade candidate

• WHEN Engineering Owner рассматривает смену поддерживаемой версии
• THEN изолированная проверка подтверждает schema, agent workflow, store selection и hard blockers до изменения version contract

Requirement: Structural и semantic verification являются разными gates

OpenSpec structural validation SHALL проверять schema, artifact graph и формальную корректность specs, но MUST NOT считаться доказательством соответствия реализации. До terminal status change MUST пройти semantic verification реализации против Proposal, Delta Specs, Design и Tasks, а затем независимый read-only review. Если основной agent entrypoint semantic verification недоступен, workflow SHALL использовать versioned эквивалентную процедуру с теми же входными артефактами, категориями проверки и наблюдаемым evidence.

Scenario: Structural validation прошла без ошибок

• WHEN все planning artifacts формально валидны, но реализация ещё не сопоставлена с ними
• THEN change не получает terminal status только на основании structural validation

Scenario: Slash workflow недоступен агенту

• WHEN среда не предоставляет установленный semantic verification entrypoint
• THEN агент выполняет документированную эквивалентную read-only проверку и сохраняет её результат вместо пропуска gate

Requirement: Archive блокируется незавершёнными tasks

Project-owned archive workflow MUST отклонять archive, если отсутствует требуемый planning artifact, любой обязательный artifact не утверждён, tasks.md отсутствует или содержит unchecked task, semantic verification либо независимый read-only review не завершены успешно, или любая affected delivery area не реализована и не прошла обязательные pre-archive gates. Workflow MUST NOT предлагать confirmation override для этих blocking conditions. Post-archive bookkeeping MUST NOT появляться как unchecked task; он SHALL фиксироваться через детерминированное Completion Evidence после успешного archive, после чего связанная delivery может получить terminal status.

Scenario: Change имеет unchecked task

• WHEN implementer запрашивает archive и остаётся хотя бы один unchecked task
• THEN workflow не архивирует change и сообщает incomplete tasks как blocking condition без возможности confirmation override

Scenario: Change не прошёл required verification

• WHEN planning artifacts и tasks завершены, но semantic verification, independent review, implementation или pre-archive gate affected area отсутствуют либо неуспешны
• THEN workflow не архивирует change и перечисляет недостающие blocking conditions

Scenario: Change завершил все tasks

• WHEN каждый planning artifact утверждён, каждый task отмечен, required verification, implementation и pre-archive gates всех affected areas успешно завершены
• THEN workflow допускает archive и фиксирует его результат через определённый completion-evidence path без создания post-archive task

Requirement: Planning artifact проверяется до запроса approval

Каждый создаваемый planning artifact SHALL пройти все применимые на его текущем этапе non-mutating structural checks до запроса approval Change Owner. Если полный change validation ещё заблокирован отсутствующими downstream artifacts, workflow MUST выполнить доступные проверки текущего artifact и явно оставить недоступную проверку незавершённой, а не заявлять общий успех. Planning verifier MUST выдавать различимые результаты для нарушения artifact validation, некорректного invocation и environment failure. Только диагностированная техническая ошибка проверяемого artifact SHALL исправляться в artifact и проверяться повторно без передачи ручного исправления Change Owner; invocation или environment failure MUST NOT приводить к изменению planning artifact. Structural success MUST NOT подменять semantic approval.

Scenario: Текущий artifact имеет проверяемое нарушение

• WHEN сгенерированный planning artifact нарушает обязательный формат или ссылочную целостность, доступные для проверки на текущем этапе
• THEN workflow сообщает artifact validation failure, исправляет указанное нарушение и повторяет structural checks до запроса owner approval

Scenario: Verifier вызван некорректно

• WHEN planning verifier получает отсутствующий или недопустимый input
• THEN он сообщает invocation failure, а агент исправляет вызов без изменения planning artifact

Scenario: Проверка блокируется окружением

• WHEN verifier не может выполнить проверку из-за отсутствующего runtime, command или иного environment prerequisite
• THEN он сообщает environment failure, агент сохраняет planning artifact неизменным и диагностирует prerequisite либо передаёт точную блокирующую ошибку Change Owner

Scenario: Downstream artifacts ещё отсутствуют

• WHEN Proposal создан, а Delta Specs, Design и Tasks ещё не существуют
• THEN workflow сообщает результат доступных Proposal checks и не представляет отсутствующую full-change validation как успешную

Requirement: Project schema сохраняет заметные самодостаточные правила

Project schema SHALL показывать обязательные правила текущей стадии до поддерживающих пояснений и SHALL сохранять нормативную семантику artifact graph, artifact boundaries и feedback routing внутри schema. Она MUST NOT зависеть от global agent prompt или параллельного файла правил для корректного выполнения workflow. Поясняющий текст SHALL использовать основной язык project artifacts, сохраняя exact OpenSpec headings, tokens, commands и normative keywords без перевода. Сокращение или перегруппировка instructions MUST NOT удалять действующий lifecycle invariant.

Scenario: Агент получает instruction текущего artifact

• WHEN OpenSpec возвращает agent instruction для разрешённой стадии
• THEN обязательные правила этой стадии доступны до подробностей и достаточны без внешнего prompt с дублирующей policy

Scenario: Instructions сокращаются

• WHEN повторяющийся или поясняющий текст удаляется либо переносится внутри project schema
• THEN каждый ранее действующий artifact boundary, approval gate и feedback route остаётся представлен ровно одним authoritative правилом

Requirement: Delta Spec template не предрешает операцию

Исходная форма Delta Spec SHALL быть применима к ADDED, MODIFIED, REMOVED и RENAMED requirements и MUST NOT создавать активный пустой раздел или предварительно выбирать одну delta operation. Она SHALL сообщать допустимые формы operations и отдельное правило Purpose для новой capability, не заставляя существующую capability начинать с ADDED Requirements.

Scenario: Изменяется существующий requirement

• WHEN агент получает исходную форму Delta Spec для существующей capability
• THEN форма позволяет выбрать MODIFIED Requirements без удаления заранее созданного активного ADDED Requirements

Scenario: Delta использует одну операцию

• WHEN change требует только одну из поддерживаемых delta operations
• THEN сохранённый artifact содержит только применимую operation и не содержит пустых sections остальных видов

Requirement: Apply читает только разрешённый planning context

Apply SHALL прочитать каждый artifact path из contextFiles, возвращённых OpenSpec для текущего change, а затем применимые локальные routing instructions каждой affected delivery area. Агент MUST NOT вычислять planning context paths самостоятельно или требовать отдельный project context mapping, дублирующий CLI-resolved state.

Scenario: OpenSpec возвращает contextFiles

• WHEN агент начинает Apply утверждённого change
• THEN он читает все объявленные CLI paths и локальные instructions affected areas до выполнения pending tasks

Scenario: У change нет отдельного context map

• WHEN CLI уже разрешил planning artifacts и affected areas имеют локальные routing instructions
• THEN Apply использует эти authorities и не блокируется отсутствием второго context mapping artifact

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

Requirement: UI/UX-проработка Design соразмерна изменению

Design SHALL явно определять применимость UI/UX: новый или существенно изменённый интерфейс, переиспользование согласованного решения либо N/A с конкретной причиной отсутствия влияния на интерфейс. Для применимого scope Design SHALL давать Change Owner однозначное представление ожидаемого результата: затронутые экраны, применимые состояния, взаимодействия и адаптивное поведение. Ссылки на переиспользуемое решение SHALL указывать, какая его часть применима к change и какие различия остаются. Неизменяемые части интерфейса и N/A MUST NOT требовать формальных новых макетов.

Scenario: Change существенно меняет интерфейс

• WHEN Design описывает новый или существенно изменённый пользовательский интерфейс
• THEN владелец может оценить затронутые экраны, применимые состояния, взаимодействия и поведение при изменении доступного пространства до реализации

Scenario: Используется согласованное решение

• WHEN change переиспользует ранее согласованное UI/UX-решение
• THEN Design однозначно указывает применимое решение, область переиспользования и различия без обязательного повторного рисования

Scenario: Change не влияет на интерфейс

• WHEN UI/UX неприменим по конкретной причине, приведённой в Design
• THEN пакет Design допускается без формального макета и дополнительных UI/UX approvals

Requirement: Визуальный пакет Design имеет однозначную сохраняемую версию

Canonical Design SHALL однозначно определять состав и версию своих применимых визуальных материалов. Материалы SHALL оставаться доступны Change Owner, исполнителю и независимому reviewer при передаче между изолированными сессиями и после archive, без зависимости от временного контекста предыдущей сессии. Ссылка, содержимое которой может молча измениться, MUST NOT быть единственным свидетельством согласованной версии. Визуальные материалы MUST NOT создавать конкурирующий versioned planning root вне canonical OpenSpec authority.

Scenario: Design передаётся другому исполнителю

• WHEN новая изолированная сессия получает canonical Design
• THEN она может однозначно найти полный применимый визуальный пакет и определить именно ту версию, на которую распространяется approval

Scenario: Визуальный источник изменился или недоступен

• WHEN текущий внешний или временный источник отличается от согласованной версии либо перестал открываться
• THEN согласованная версия остаётся доступна из сохраняемого пакета Design и не заменяется молча новым содержимым

Scenario: Change архивирован

• WHEN участник обращается к Design после archive
• THEN применимые визуальные материалы согласованной версии доступны вместе с архивным Design и сохраняют однозначную связь с ним

Requirement: Соответствие визуальному Design входит в semantic verification

Реализация SHALL следовать утверждённому Design, включая его применимые визуальные материалы. Semantic verification и независимый read-only review SHALL сопоставлять реализованные экраны, состояния, взаимодействия и адаптивное поведение с этим пакетом в границах change. Наличие каталога или макета MUST NOT считаться approval или доказательством соответствия реализации. Несоответствие реализации SHALL направляться на исправление реализации; необходимость существенно изменить согласованный результат SHALL возвращать работу к самой ранней затронутой planning boundary с действующими cascade approval rules.

Scenario: Реализация расходится с согласованным интерфейсом

• WHEN реализация не соответствует однозначному применимому решению Design
• THEN проверка сообщает наблюдаемое несоответствие для исправления реализации и не объявляет соответствие только из-за наличия макета или каталога

Scenario: Согласованное решение требует пересмотра

• WHEN выполнить UI/UX-решение без существенного изменения утверждённого результата невозможно либо planning artifacts противоречат друг другу
• THEN workflow возвращает работу к самой ранней затронутой planning boundary, применяет cascade approval rules и не подгоняет Design под реализацию

Requirement: Внедрение UI/UX workflow сохраняет действующие approval boundaries

Planning integrate-ui-ux-design-workflow MAY продолжаться до завершения optimize-session-oriented-sdd-v2, но внедрение процессной части MUST ожидать его завершения. Перед Design этого change workflow SHALL повторно сверить действующую canonical authority и определить применимость обновлённого процесса к активным changes. Обновление MUST NOT автоматически переутверждать их artifacts или переписывать historical archives.

Scenario: Предшествующий процессный change ещё не завершён

• WHEN optimize-session-oriented-sdd-v2 остаётся незавершённым
• THEN planning текущего change допускается в рамках явных approvals, а внедрение его процессной части остаётся недоступным

Scenario: Начинается Design интеграции

• WHEN Delta Specs этого change явно утверждены и начинается Design
• THEN Design опирается на повторно сверенную текущую canonical authority и явно определяет применимость процесса к активным changes

Scenario: Обновлённый процесс поставляется

• WHEN процессные изменения становятся доступными участникам
• THEN прежние approvals активных changes не считаются автоматически обновлёнными, а historical archives сохраняются без переписывания

Requirement: Готовность к пилоту отделена от доказанной успешности workflow

Поставка каталога и обновлённого процесса SHALL позволять использовать их совместно в последующем небольшом UI change с собственными planning approvals. Текущий change MUST NOT включать неявную продуктовую фичу в качестве пилота или заявлять успешность сквозного workflow до его фактического прохождения.

Scenario: Текущая поставка завершена

• WHEN каталог и обновлённый процесс готовы к совместному использованию, но последующий UI change ещё не прошёл workflow
• THEN результат описывается как готовность к пилоту без заявления об успешном сквозном пилоте

Scenario: Начинается пилотный UI change

• WHEN владелец выбирает небольшой UI change для совместного использования каталога и процесса
• THEN этот change проходит собственные planning approvals, а вывод о сквозной успешности опирается только на его фактически наблюдаемый результат