Archive verified UI design workflow and Storybook delivery
Native archive synchronized 8 added and 3 modified requirements. All 24 main specs pass strict validation. Independent completion-output review confirms all 8 archived files preserve their bytes and all unrelated main specs remain unchanged. Product pilot remains a separate future change.
This commit is contained in:
@@ -65,6 +65,14 @@ 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
|
||||
@@ -91,6 +99,26 @@ artifacts MUST быть источником intent, requirements, design и tas
|
||||
- **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: Handoff не заменяет canonical OpenSpec authority
|
||||
|
||||
Workflow handoff SHALL сохранять только состояние перехода, краткий observed
|
||||
@@ -137,6 +165,11 @@ PASS, FAIL либо SPEC_ISSUE с маршрутизацией к Finalization,
|
||||
самой ранней затронутой 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,
|
||||
@@ -163,6 +196,20 @@ review MUST NOT оставаться unchecked implementation Tasks.
|
||||
- **THEN** завершение Implementation не зависит от checkbox, который может
|
||||
закрыть только Validation
|
||||
|
||||
#### Scenario: Найдено визуальное несоответствие
|
||||
|
||||
- **WHEN** наблюдаемая реализация расходится с однозначным применимым решением
|
||||
согласованного визуального пакета
|
||||
- **THEN** Validation возвращает FAIL с конкретным несоответствием и не
|
||||
исправляет интерфейс или визуальный пакет в этой сессии
|
||||
|
||||
#### Scenario: Визуальный пакет противоречит другим planning artifacts
|
||||
|
||||
- **WHEN** Validation обнаруживает противоречие согласованного визуального
|
||||
результата требованиям либо неоднозначность самого Design
|
||||
- **THEN** она возвращает SPEC_ISSUE с основанием возврата к самой ранней
|
||||
затронутой planning boundary, не выбирая новую трактовку самостоятельно
|
||||
|
||||
### Requirement: Finalization требует успешной независимой Validation
|
||||
|
||||
Workflow SHALL разрешать Finalization только после последней независимой
|
||||
|
||||
@@ -0,0 +1,95 @@
|
||||
# frontend-ui-catalog Specification
|
||||
|
||||
## Purpose
|
||||
Предоставляет участникам разработки воспроизводимый обзор ограниченного набора
|
||||
реальных UI-компонентов и композиций WealthLedger для выбора решений на
|
||||
общей визуальной основе приложения.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement: Каталог предоставляет определённый набор реальных компонентов
|
||||
|
||||
Участники разработки SHALL иметь один доступный каталог с явно определённым
|
||||
ограниченным набором реальных компонентов и UI-композиций WealthLedger, их
|
||||
назначением, поддерживаемыми вариантами, применимыми состояниями и правилами
|
||||
использования. Основное содержание SHALL показывать решения, используемые
|
||||
приложением. Библиотечные примитивы MAY быть вспомогательными примерами принятых
|
||||
конфигураций, но MUST NOT подменять продуктовые компоненты и композиции. Каталог MUST демонстрировать реальное
|
||||
поведение компонентов на общей визуальной основе приложения, а не независимые
|
||||
имитации. Отсутствие компонента в каталоге MUST NOT означать его отсутствие в
|
||||
приложении или запрет использования.
|
||||
|
||||
#### Scenario: Участник выбирает готовое решение
|
||||
|
||||
- **WHEN** участник просматривает включённый в каталог компонент
|
||||
- **THEN** он видит его назначение, доступные варианты и состояния и может
|
||||
сопоставить их с потребностью интерфейса на визуальной основе WealthLedger
|
||||
|
||||
#### Scenario: Участник изучает принятый UI-паттерн
|
||||
|
||||
- **WHEN** участник выбирает композицию или компонент из основного набора
|
||||
- **THEN** он видит реальное решение WealthLedger, его назначение, состояния и
|
||||
ограничения применения, а не только стандартный пример UI-библиотеки
|
||||
|
||||
#### Scenario: Компонент не входит в начальный набор
|
||||
|
||||
- **WHEN** участник ищет компонент за пределами объявленного набора
|
||||
- **THEN** граница покрытия каталога остаётся явной, без заявления о полноте
|
||||
каталогизации приложения
|
||||
|
||||
### Requirement: Примеры воспроизводят состояния и взаимодействия изолированно
|
||||
|
||||
Каталог SHALL позволять воспроизводимо просматривать объявленные варианты и
|
||||
состояния без прохождения полного пользовательского сценария приложения.
|
||||
Интерактивные примеры SHALL позволять наблюдать поддерживаемые взаимодействия.
|
||||
Примеры MUST сохранять применимые правила доступности и UI-состояний приложения
|
||||
и MUST NOT вводить конкурирующую модель их поведения. Состояния, неприменимые к
|
||||
компоненту, MUST NOT требоваться только ради заполнения каталога.
|
||||
|
||||
#### Scenario: Участник повторно открывает пример
|
||||
|
||||
- **WHEN** участник повторно выбирает тот же объявленный вариант и состояние
|
||||
- **THEN** каталог воспроизводит соответствующий пример без предварительного
|
||||
прохождения инвестиционного сценария
|
||||
|
||||
#### Scenario: Участник взаимодействует с компонентом
|
||||
|
||||
- **WHEN** участник использует поддерживаемое взаимодействие интерактивного
|
||||
примера, включая клавиатурное управление там, где оно применимо
|
||||
- **THEN** доступное поведение, focus и ограничения состояния соответствуют
|
||||
реальному компоненту приложения
|
||||
|
||||
#### Scenario: Представлено запросное состояние
|
||||
|
||||
- **WHEN** пример показывает применимое loading, error, empty или loaded
|
||||
состояние либо отображение ранее полученных данных при refetch
|
||||
- **THEN** пример сохраняет действующую семантику соответствующего состояния
|
||||
приложения и не подменяет её новой каталоговой договорённостью
|
||||
|
||||
### Requirement: Каталог сохраняет достоверность и границы демонстрации
|
||||
|
||||
Каталог SHALL отражать фактические поддерживаемые возможности включённых
|
||||
компонентов и общие визуальные правила приложения. Демонстрационные данные
|
||||
MUST NOT требовать доступа к реальным финансовым данным или секретам пользователя;
|
||||
действия в примерах MUST NOT изменять реальные пользовательские данные. Известное
|
||||
ограничение воспроизведения MUST быть явно обозначено и MUST NOT представляться
|
||||
как подтверждённое продуктовое поведение.
|
||||
|
||||
#### Scenario: Возможность компонента изменилась
|
||||
|
||||
- **WHEN** изменённая возможность включённого компонента поставляется
|
||||
- **THEN** каталог показывает соответствующее фактическое поведение и не
|
||||
представляет устаревший вариант как поддерживаемый
|
||||
|
||||
#### Scenario: Участник выполняет демонстрационное действие
|
||||
|
||||
- **WHEN** участник открывает пример или выполняет в нём действие
|
||||
- **THEN** для демонстрации не требуются реальные пользовательские финансовые
|
||||
данные или секреты и реальные пользовательские данные остаются неизменными
|
||||
|
||||
#### Scenario: Изолированный пример имеет ограничение
|
||||
|
||||
- **WHEN** пример не воспроизводит некоторый аспект полного пользовательского
|
||||
сценария
|
||||
- **THEN** участник видит это ограничение и не получает заявления о проверке
|
||||
полного сценария на основании примера
|
||||
@@ -7,7 +7,7 @@
|
||||
|
||||
### Requirement: SDD-артефакты имеют непересекающиеся полномочия
|
||||
|
||||
Proposal SHALL выражать причину, намерение, границы и ожидаемый эффект change языком владельца и MUST NOT содержать решения по технологиям, структуре кода, файлам, API или зависимостям. Delta Specs SHALL определять только добавленное, изменённое или удалённое наблюдаемое поведение и инварианты системы без описания изменений кода. Design SHALL объяснять архитектурный способ выполнения утверждённых Specs, существенные решения, риски и альтернативы крупными частями и MUST NOT становиться построчной инструкцией реализации. Tasks SHALL быть implementation checklist, достаточным для выполнения Design и Specs, и MUST NOT содержать ещё не наблюдённые completion results, commit identifiers или post-archive bookkeeping. Completion Evidence SHALL фиксироваться только после фактической реализации и верификации и MUST NOT подменять planning artifact.
|
||||
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
|
||||
|
||||
@@ -19,6 +19,18 @@ Proposal SHALL выражать причину, намерение, границ
|
||||
- **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.
|
||||
@@ -281,3 +293,134 @@ approval, workflow MUST повторно запросить решение Chang
|
||||
|
||||
- **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, а вывод о
|
||||
сквозной успешности опирается только на его фактически наблюдаемый результат
|
||||
|
||||
Reference in New Issue
Block a user