specs/openspec/changes/archive/2026-09-07-integrate-ui-ux-design-workflow/specs/agent-sdd-session-workflow/spec.md

MODIFIED Requirements

Requirement: Продолжение workflow восстанавливает только нужный контекст

Workflow SHALL однозначно определять текущую роль и разрешённый outcome из сохранённого состояния change и одного актуального self-contained handoff. Он MUST загружать только phase-specific canonical authority и изменившийся relevant evidence, а не полную историю, прежние handoff-данные или уже прочитанные неизменившиеся inputs. После появления OpenSpec change его approved artifacts MUST быть источником intent, requirements, design и tasks.

Specification при подготовке Design SHALL определять применимый визуальный пакет в canonical Design. При продолжении после его approval Implementation и Validation SHALL получать применимые визуальные материалы именно согласованной версии из canonical Design, сохраняя одну роль сессии и не создавая копию Design в handoff. Недоступность или неоднозначность согласованного пакета MUST быть сообщена как блокер зависимой работы и MUST NOT компенсироваться догадкой по истории обсуждения или текущему внешнему макету.

Scenario: Пользователь продолжает change после другой сессии

• WHEN пользователь запрашивает продолжение известного change
• THEN workflow определяет ровно одну текущую роль, читает только актуальный handoff и применимую canonical authority этой роли

Scenario: Есть история нескольких попыток

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

Scenario: Независимые evidence доступны одновременно

• WHEN до следующего смыслового решения нужны несколько независимых read-only inputs
• THEN workflow получает их одним bounded batch и сохраняет полный relevant scope для failure или review findings

Scenario: Успешный gate уже выполнен на неизменившихся inputs

• WHEN успешный gate был выполнен и его relevant inputs после этого не изменялись
• THEN workflow использует сохранённый observed outcome и не повторяет gate без причины

Scenario: Specification готовит Design с визуальными материалами

• WHEN Specification получила разрешение подготовить Design с применимым UI/UX scope
• THEN она представляет визуальные материалы как часть одного canonical Design и останавливается до его единого approval, не начиная другую роль

Scenario: Implementation получает утверждённый визуальный Design

• WHEN Implementation начинает разрешённую реализацию UI change
• THEN она использует применимый пакет согласованной версии из canonical Design, а навигационный handoff не заменяет его содержимое или owner approval

Scenario: Пакет невозможно однозначно восстановить

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

Requirement: Validation остаётся независимой и без побочных исправлений

Validation SHALL независимо выполнять affected canonical gates, semantic и acceptance verification, проверку применимых edge cases и independent read-only review относительно approved OpenSpec artifacts. Она MUST NOT изменять production implementation, specification или Tasks и MUST возвращать только PASS, FAIL либо SPEC_ISSUE с маршрутизацией к Finalization, Implementation либо самой ранней затронутой planning boundary. Validation-owned verification и review MUST NOT оставаться unchecked implementation Tasks.

Для применимого UI/UX scope независимое сопоставление SHALL включать визуальные материалы согласованной версии canonical Design и соответствующие экраны, состояния, взаимодействия и адаптивное поведение реализации. Read-only boundary Validation SHALL распространяться на весь визуальный пакет Design.

Scenario: Реализация соответствует утверждённому change

• WHEN Validation подтверждает approved requirements, affected gates, acceptance behavior и отсутствие blocking review findings
• THEN она возвращает PASS и разрешает следующую сессию Finalization

Scenario: Найдена проблема реализации

• WHEN Validation находит несоответствие реализации утверждённому OpenSpec
• THEN она возвращает FAIL с точным observed finding и направляет следующую сессию к Implementation без самостоятельного исправления

Scenario: Найдена проблема спецификации

• WHEN Validation находит противоречие или пробел в approved planning artifacts
• THEN она возвращает SPEC_ISSUE и направляет работу к самой ранней затронутой planning boundary без переписывания specification под реализацию

Scenario: Tasks планируют независимую проверку

• WHEN Tasks описывают ожидаемую semantic verification или independent review после реализации
• THEN завершение Implementation не зависит от checkbox, который может закрыть только Validation

Scenario: Найдено визуальное несоответствие

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

Scenario: Визуальный пакет противоречит другим planning artifacts

• WHEN Validation обнаруживает противоречие согласованного визуального результата требованиям либо неоднозначность самого Design
• THEN она возвращает SPEC_ISSUE с основанием возврата к самой ранней затронутой planning boundary, не выбирая новую трактовку самостоятельно