## 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, не выбирая новую трактовку самостоятельно