09. Библиотека примеров

Восемь сценариев (E1–E8): шесть примеров in-doc (E3–E8) + два walkthrough (E1–E2). Каждый in-doc пример проходит цепочку ТЗ → ADAPT → BR/SR → SPEC → TC → QG целиком или частично.

#	Сценарий	Документ	Аудитория	Акцент
E1	Email/password sign-up (минимальный)	00-quickstart	Новичок	30 мин, минимум артефактов
E2	Login + profile + permissions (полный)	01-walkthrough	Tech Lead, QA	Полный lifecycle, AI-генерация TC
E3	Экспорт персональных данных (GDPR / ФЗ-152)	§2	Legal, PM, Architect	Compliance, SPEC-DATA/SEC
E4	Webhook idempotency (REST API)	§3	Backend, Architect	tc-type: contract, SPEC-API
E5	RAG-ассистент (SPEC-AI eval)	§4	AI engineer	tc-type: eval, judge isolation
E6	Delta-ТЗ: scope dispute	§5	PM, Client, Architect	ADAPT backward, неизменяемое ТЗ
E7	Подсистема как самостоятельный продукт	§6	Architect	Ребро implements[], §6.8.2
E8	Интерфейсная часть E3: пример до конца	§7	UI/UX, Architect, QA	Заполненные тела SR / SPEC-UI / ux-TC

---

2. E3 — Экспорт персональных данных (GDPR Art. 15 / ФЗ-152)

Контекст: SaaS «AcmeCRM» хранит PII клиентов. Регулятор и договор обязывают выдать машиночитаемый экспорт по запросу субъекта данных за ≤30 дней.

2.1 Фрагмент ТЗ (immutable)

# TZ-2026-002 — Data subject export

§3.1 Субъект данных может запросить полный экспорт своих PII через UI «Privacy → Export my data».
§4.2 Формат: JSON + CSV bundle, zip, checksum SHA-256.
§4.3 SLA: готовность ссылки на скачивание ≤ 72 часа с момента verified identity.
§4.4 Экспорт включает: profile, activity log 24 мес., marketing consents.
§4.5 Запрос логируется; повторный экспорт — не чаще 1 раза в 30 дней без переопределения администратором.

2.2 ADAPT (сокращённо)

id: ADAPT-002
type: ADAPT
status: approved
source-tz: { id: TZ-2026-002, signed-date: "2026-05-01" }

Forward §3: экспорт асинхронный (job queue); identity — через существующий MFA flow.

Backward (resolved):

#	Finding	Resolution
B-01	«24 мес. activity» — calendar или rolling?	Rolling 730 days
B-02	Override admin — кто approves?	Role privacy-officer + журнал аудита

2.3 BR + SR

# br/BR-02-data-subject-export.md
id: BR-02
type: BR
title: "Субъект данных получает машиночитаемый экспорт PII"
source: { adapt: ADAPT-002, adapt-section: "Forward §3" }
compliance:
  - { standard: GDPR, control: "Art. 15" }
  - { standard: "ФЗ-152", control: "ст.14" }

# sr/SR-08-export-request.md
id: SR-08
type: SR
parent: { id: BR-02 }
title: "Authenticated user инициирует export job"
constrained-by: ["SPEC-API-04", "SPEC-DATA-02", "SPEC-SEC-03"]

# sr/SR-09-export-delivery.md
id: SR-09
type: SR
parent: { id: BR-02 }
title: "User скачивает готовый bundle по time-limited signed URL"
constrained-by: ["SPEC-API-04", "SPEC-SEC-03"]

2.4 SPEC (выдержки)

SPEC-DATA-02 — schema export bundle (tables: users, activity_events, marketing_consents).

SPEC-SEC-03 — signed URL TTL 24h; rate limit 1 export / 30 days; role privacy-officer для override.

SPEC-API-04 — POST /v1/privacy/export, GET /v1/privacy/export/{job_id}.

2.5 TC (pos/neg для SR-08)

---
id: TC-080
title: "Export job создаётся для verified user"
type: TC
tc-type: system
automation: { status: automated, set-version: "1.0" }
verifies:
  - id: SR-08
negative: false
---
## When
POST /v1/privacy/export (session: verified-user)
## Then
- 202 + job_id; status pending; audit event recorded

---
id: TC-081
title: "Export отклонён без MFA-verified session"
type: TC
tc-type: security
automation: { status: automated, set-version: "1.0" }
verifies:
  - id: SR-08
negative: true
---
## When
POST /v1/privacy/export (session: password-only, no MFA)
## Then
- 403; job не создан; security audit event

Аналогичные пары для SR-09 (signed URL valid / expired).

2.6 Контрольные точки качества

Контрольная точка	Доказательства
QG-ADAPT-approve (по смыслу около «архитектурной точки»: QG-3)	ADAPT-002 в approved, замечания backward закрыты
QG-2 Verification Gate	TC-080…081 успешны; в last-run совпадает set-version (1.0)

2.7 Что дальше

• Полный сценарий под git — 03-tool-guide-git
• Compliance mapping — 06-compliance
• Conformance manifest — reference/08
• Интерфейсная часть этого же примера, доведённая до заполненных тел — §7 E8

---

3. E4 — Webhook idempotency (SPEC-API)

Контекст: платёжный провайдер шлёт POST /webhooks/payment с Idempotency-Key. Дубликаты не должны создавать двойное списание.

ТЗ (фрагмент): «Повторный webhook с тем же key в течение 24h возвращает тот же payment_id, HTTP 200».

SR + SPEC:

id: SR-20
type: SR
constrained-by: ["SPEC-API-07"]

SPEC-API-07 — контракт: headers, body schema, response codes 200/400/409.

TC (contract pair):

id: TC-200
type: TC
tc-type: contract
verifies: [{ id: SR-20 }]
negative: false

id: TC-201
type: TC
tc-type: contract
verifies: [{ id: SR-20 }]
negative: true

Neg: второй key с другим body → 409 Conflict.

Контрольная точка QG-2: оба TC успешны; в last-run совпадает set-version (1.0).

---

4. E5 — RAG assistant (SPEC-AI)

Контекст: in-app чат отвечает по knowledge base; eval против golden Q&A set.

SPEC-AI-02 — model card, fallback, cost cap.

TC eval (judge ≠ production):

id: TC-300
type: TC
tc-type: eval
verifies: [{ id: SPEC-AI-02 }]
judge:
  vendor: "<vendor>"
  model: "eval-judge-v2"          # ≠ production-модели из SPEC-AI-02 (§9.6.2)
baseline:
  artifact: "<golden Q&A dataset>"
  metric-thresholds: {}
negative: false

Neg eval: prompt injection в user message → refusal + audit event (tc-type: eval, adversarial negative).

См. standard/09 §9.6.2, guide/07 §3.5.

---

5. E6 — Delta-ТЗ: scope dispute

Контекст: после signed TZ клиент просит «добавить экспорт в PDF» — вне scope ADAPT-002.

Правильный путь к источнику истины (SoT):

1. Не править неизменяемое ТЗ и не молча расширять SR.
2. Оформить delta-ТЗ; состязательный рецензент проводит обзор и выносит вердикт (§7.6.1). При вердикте «findings present» создаётся delta-ADAPT ADAPT-002-delta-1 (forward + backward); при «no findings» delta-ADAPT не создаётся, а производные артефакты ссылаются на source.tz-section delta-ТЗ.
3. Backward finding: «PDF export не входил в Forward §3 ADAPT-002».
4. Решение клиента по находке оформляется ACTZ — протоколом уточнения ТЗ с двусторонней подписью (standard/07 §7.13); находка получает decided-in: ACTZ-003 §1.
5. Delta-ADAPT утверждается подписью архитектора (§7.5) → новые SR/SPEC/TC. Итоговое ТЗ пересчитывается, AT перегенерируются от новой редакции.

Anti-pattern: direct commit в sr/SR-08 без delta-ref — drift class 4.11.6 (standard/04 §4.11).

См. standard/07 §7.6, guide/02-transition-guide.

---

6. E7 — Подсистема как самостоятельный продукт (implements-edge)

Контекст: платформа acme (система) состоит из подсистемы acme.notify — отдельный продукт с собственным бизнес-владельцем (Notify Lead), отдельной командой, отдельным releases-циклом. Сценарий §6.8.2 RENAR Standard.

6.1 Иерархия артефактов

acme (система)
├── BR-01 (приём заказов с AI-консультацией)            level: system
├── BR-05 (мониторинг и алерты для операционной службы)  level: system
└── acme.notify (подсистема, самостоятельный продукт)
    └── BR-01 (доставка уведомлений по multichannel)    level: subsystem
         implements:
           - id: BR-01      (раскрывает «приём заказов»: уведомления при изменениях статуса)
             scope: { system: acme }
           - id: BR-05      (раскрывает «мониторинг»: уведомления о SLA-нарушениях)
             scope: { system: acme }
         ↓
         SR-01..SR-12 (notify-внутренние требования)
         SPEC-INT-01 (интеграция с acme через message bus)
         SPEC-API-01 (REST API для notify-клиентов)

acme.notify.BR-01 — корневой узел своего дерева требований (parent отсутствует, как и у любого BR). Связь с системой выражена типизированным ребром implements[], не parent-edge.

6.2 frontmatter acme.notify/br/BR-01-multichannel-delivery.md (фрагмент)

---
id: BR-01
title: "Доставка уведомлений по multichannel"
type: BR
level: subsystem
scope:
  system: acme
  subsystem: acme.notify

owner: "Notify Lead (notify-side); Architect (acme-side)"

source:
  adapt: ADAPT-NOTIFY-001
  adapt-section: "Forward §2"
  tz-section: "ТЗ-NOTIFY §3"

# === implements-edge §6.8.2 ===
implements:
  - id: BR-01
    scope:
      system: acme
    rationale: "ADAPT-NOTIFY-001 §2.1 — уведомления при изменении статуса заказа"
  - id: BR-05
    scope:
      system: acme
    rationale: "ADAPT-NOTIFY-001 §2.4 — алерты SLA для operations"

business-context:
  stakeholder: "Notify Lead"
  business-goal: "Своевременная доставка уведомлений end-customer и operations team"
---

# BR-01: Доставка уведомлений по multichannel

Notify-подсистема доставляет уведомления …

6.3 Машиночитаемая trace chain

TC-NOTIFY-15
  → verifies SR-NOTIFY-08 (rate-limit для email канала)
        ├─ parent:   acme.notify.BR-01 v1.2
        │              └─ implements: acme.BR-01 v3.0, acme.BR-05 v1.4
        │                              (типизированное межуровневое ребро)
        ├─ source.adapt: ADAPT-NOTIFY-001 §Forward §2.2
        └─ constrained-by: SPEC-API-01, SPEC-OPS-01   (scope: acme.notify)

При аудите от TC-NOTIFY-15 восстанавливается полная цепочка: SR → BR подсистемы → BR системы. До v1.0 (без implements-edge) цепочка обрывалась на acme.notify.BR-01 и продолжалась только через текст раздела «Контекст».

6.4 Гейты на стороне носителя

При попытке approve acme.notify.BR-01 нативный для носителя hook проверяет (см. standard/10 §10.11.1):

1. acme.BR-01 и acme.BR-05 существуют в носителе по id + scope.system.
2. Оба target BR входят в утверждённую версию комплекта своей системы.
3. Цепочка acme.notify.BR-01 → acme.BR-01 → … не образует цикла.
4. acme.notify.BR-01.level = subsystem (правило: implements[] не применяется на level: system).

Если любая проверка проваливается — approve блокируется. Поведение при acme.BR-01 = deprecated: warning, не fatal (Architect решает: обновить implements на актуальный BR или отметить acme.notify.BR-01 как требующий пересмотра).

6.5 Эволюция «модуль → подсистема» через implements

Когда модуль приобретает бизнес-владельца (standard/06 §6.9.1):

1. Бизнес-владелец фиксируется через backward finding ADAPT (категория scope).
2. После approved delta-ADAPT — модуль повышается до подсистемы; создаётся BR подсистемы.
3. Новый шаг (v1.0+): BR подсистемы декларирует implements[] на applicable BR системы. Без этого шага сценарий §6.8.2 несёт несовместимое с v1.1 conformance отсутствие traceability.

Anti-pattern: создать acme.notify.BR-01 с level: subsystem, но без implements[] — формально допустимо на v1.0 (recommended), но non-conformant на v1.1+. Если родительская система имеет approved BR, отсутствие implements[] обязано быть явно обосновано в разделе «Контекст» BR со ссылкой на ADAPT§.

См. standard/06 §6.5.2, §6.8.2, §6.10.3, standard/13 §13.3.8.

7. E8 — Интерфейсная часть E3: пример, доведённый до конца

Информативный раздел. Пример не является нормативным текстом и не создаёт обязательств. При расхождении с главами стандарта верны главы. Нормативные требования, которым пример следует, названы в каждом подразделе ссылкой.

Зачем он здесь. Остальные примеры библиотеки останавливаются на frontmatter и выдержках: они показывают оболочку артефакта — идентификаторы, статусы, рёбра графа. Но агент, выводящий реализацию, читает не оболочку, а утверждение. E8 продолжает E3 (§2) интерфейсной частью и доводит до конца три тела, которых в корпусе не было ни одного: тело SR (standard/06 §6.6.3), тело SPEC-UI (standard/08 §8.5.6) и пару ux-TC (standard/09 §9.6.1).

Что именно он доказывает — и чего не доказывает. Границу лучше провести сразу, до чтения. Пример проверяет форму обязательного тела: что разделы §8.4.1 и §8.5.6 заполняются осмысленно, что требование «покрыть каждое доступное через интерфейс действие» операционализуемо, что ux-TC пишется по §9.6.1 без изобретения полей. Пример не проверяет объём: в нём три экрана, и на трёх экранах вывод «требование всех экранов подъёмно на реальной системе» заработать нельзя.

---

7.1 Граница «всех экранов» проходит по Scope спецификации

Одна частность §8.5.6 обнаруживается только при попытке написать тело, и её стоит назвать до примера.

Формулировка обязательного тела SPEC-UI требует описать «все экраны системы». Буквально прочитанная, она означала бы, что один SPEC-UI обязан описать интерфейс всей системы целиком — от входа до администрирования. Так она не работает и так не задумана: границу описываемого проводит раздел Scope того же обязательного тела (standard/08 §8.4.1, пункт 2), а «все экраны» означает полноту внутри объявленного Scope, без отбора по значимости.

Обе половины существенны:

• Scope сужать можно — он часть обязательного тела и объявляется явно, поэтому не попавшее в него не теряется молча, а видно как граница.
• Внутри Scope отбирать нельзя — именно это запрещает положение «Полнота охвата» §8.4.1: не «опишите важные экраны выгрузки», а «опишите все экраны выгрузки».

Ниже Scope объявлен интерфейсом выгрузки персональных данных; экранов в нём три, и описаны все три.

Полнота по системе — перечень экранов. Scope и §8.4.1 дают полноту внутри документа; что сумма всех SPEC-UI покрывает интерфейс целиком, обеспечивают перечень экранов в обязательном теле SPEC-ARCH-01 системы E3 и правило покрытия (standard/08 §8.5.6.1). В §2.4 SPEC-ARCH-01 не приводился; здесь — та часть его перечня, которая касается раздела «Приватность»:

Код	Экран	Источник	Покрывающий SPEC-UI
Э-01	Запрос выгрузки	SR-10	SPEC-UI-02
Э-02	Выгрузка готовится	SR-10	SPEC-UI-02
Э-03	Запрос отклонён	SR-10	SPEC-UI-02
Э-04	Подтверждение личности вторым фактором	SR-08	SPEC-UI-01
Э-05	Выдача переопределения (роль privacy-officer)	SPEC-ARCH-01, контейнер «Кабинет privacy-officer»	—

Последняя колонка — не часть перечня, а итог проверки при утверждении версии комплекта: перечень ведёт SPEC-ARCH, покрытие объявляет каждый SPEC-UI в screens[]. Э-05 в перечне есть, а SPEC-UI на него нет — версия комплекта с таким перечнем не утверждается (standard/10 §10.7.2), пока экран не описан либо не исключён из перечня решением, видимым в записи версии. Источник перечня — только описание: SR-08 и SR-10 называют экраны, SPEC-ARCH-01 — контейнер кабинета; маршрут, найденный в реализации и отсутствующий в перечне, — дрейф источника истины и обратная находка, а не основание пополнить перечень задним числом.

---

7.2 SR-10 — заполненное тело (§6.6.3)

Продолжает SR-08 из §2.3: тот описывает создание задачи выгрузки со стороны службы, SR-10 — со стороны интерфейса.

# sr/SR-10-export-request-ui.md
id: SR-10
type: SR
parent: { id: BR-02 }
title: "Субъект данных инициирует выгрузку через интерфейс приватности"
source: { adapt: ADAPT-002, adapt-section: "Forward §3", tz-section: "§3.1" }
constrained-by: ["SPEC-UI-02", "SPEC-SEC-03"]

Требование

Когда субъект данных подтверждает запрос на экране «Приватность → Выгрузка моих данных», система должна создать задачу выгрузки и перевести пользователя на экран состояния этой задачи.

Форма — событийная (standard/06 §6.6.3.1): маркер условия «когда» стоит первым словом и пишется строчной буквой; модальность «должна» — строчная каноническая. Утверждение одно: создание задачи и переход на экран состояния — единый наблюдаемый исход одного действия, а не два независимых требования.

Поведение

Экран запроса доступен субъекту данных в разделе «Приватность» и показывает состав выгрузки до её заказа: профиль, журнал действий за 730 календарных дней и согласия на маркетинговые рассылки (ТЗ §4.4 в §2.1, уточнение B-01 из ADAPT-002).

Пока личность субъекта не подтверждена вторым фактором, система должна держать действие «Заказать выгрузку» недоступным и показывать причину недоступности рядом с ним. Подтверждение выполняется существующим механизмом второго фактора; отдельного механизма для выгрузки не вводится.

Если с момента прошлой выгрузки прошло менее 30 дней и переопределение не выдано, то система должна отказать в заказе. Дата, начиная с которой заказ снова возможен, называется субъекту на экране отказа (ТЗ §4.5 в §2.1).

После создания задачи система показывает состояние подготовки и остаётся на экране состояния до появления ссылки на скачивание либо до истечения срока подготовки в 72 часа (ТЗ §4.3 в §2.1). Доставка готового архива нормируется отдельно — SR-09.

Каждый заказ, каждый отказ и каждое переопределение записываются в журнал аудита (ТЗ §4.5 в §2.1, уточнение B-02).

Ограничения

Срок подготовки — не более 72 часов с момента подтверждения личности. Частота — не чаще одного заказа в 30 дней без переопределения. Переопределение выдаёт участник в роли privacy-officer. Полные ограничения — в SPEC-SEC-03.

Связь с SPEC

SPEC-UI-02 нормирует интерфейсную часть: состав экранов, покрытие действий, состояния ожидания и отказа, доступность и языковые версии. SPEC-SEC-03 нормирует правило частоты, роль выдающего переопределение и срок жизни ссылки на скачивание.

---

7.3 Пять форм утверждения на одном материале

Standard/06 §6.6.3.1 вводит пять форм. На материале E3 они выглядят так — таблица показывает форму, а не полный текст требований:

Случай	Утверждение
Постоянное	Система должна записывать в журнал аудита каждый заказ выгрузки.
По состоянию	Пока личность субъекта не подтверждена вторым фактором, система должна держать действие «Заказать выгрузку» недоступным.
Событийное	Когда субъект данных подтверждает запрос, система должна создать задачу выгрузки.
Нежелательное поведение	Если с момента прошлой выгрузки прошло менее 30 дней, то система должна отказать в заказе.
Опциональная возможность	При наличии выданного переопределения система должна принять заказ раньше 30 дней.

Три частности формы видны на этих же строках: маркер «при наличии» вместо кальки «где»; обязательное «то» после «если»; одно утверждение в одном предложении — там, где хотелось написать «отказать и назвать дату», отказ и сообщение разделены на два предложения, потому что склеенное утверждение верифицируется неделимо и один TC доказывал бы половину.

---

7.4 SPEC-UI-02 — заполненное обязательное тело (§8.4.1 + §8.5.6)

# specs/ui/SPEC-UI-02-privacy-export.md
id: SPEC-UI-02
type: SPEC
spec-type: SPEC-UI
title: "Интерфейс выгрузки персональных данных"
source: { adapt: ADAPT-002, adapt-section: "Forward §3" }
depends-on: ["SPEC-SEC-03", "SPEC-API-04"]
screens: ["Э-01", "Э-02", "Э-03"]     # коды из перечня экранов SPEC-ARCH-01 (§7.1)
ui-platform: web
target-users: [{ role: data-subject, persona: "ADAPT-002 §2.1" }]
design-system: "AcmeCRM Design Kit 4"
accessibility-level: WCAG-AA
i18n: required
mockup-links: [{ tool: figma, url: "<ссылка на макет>", version: "v3" }]
baseline-images:
  - "ai-concepts/baselines/SPEC-UI-02-screen-01.png"
  - "ai-concepts/baselines/SPEC-UI-02-screen-02.png"
  - "ai-concepts/baselines/SPEC-UI-02-screen-03.png"

Назначение

Спецификация нормирует интерфейс, которым субъект данных заказывает выгрузку своих персональных данных, наблюдает за её подготовкой и получает отказ с объяснимой причиной. Она даёт агенту, реализующему интерфейс, единственный источник истины о составе экранов и о том, что на них доступно; всё, что здесь не описано, источника истины не имеет и домысливанию не подлежит (standard/02 §2.3.3).

Scope

Входит: три экрана раздела «Приватность → Выгрузка моих данных» — запрос выгрузки, состояние подготовки, отказ; все действия, доступные субъекту данных на этих экранах; сквозные элементы этих экранов.

Не входит: экран подтверждения второго фактора (Э-04 перечня: правило — SPEC-SEC-03, экран — SPEC-UI-01; переиспользуется без изменений); интерфейс участника в роли privacy-officer, выдающего переопределение (отдельная спецификация, в E8 не рассматривается); почтовое уведомление о готовности архива (не экран).

Общая структура интерфейса

Раздел «Приватность» — вкладка в настройках учётной записи. Выгрузка — один из её пунктов; экраны выгрузки образуют линейную последовательность без ветвлений: запрос → состояние, либо запрос → отказ. Возврат в настройки доступен с любого из трёх экранов. Всплывающих окон в разделе нет: отказ и состояние — полноценные экраны, потому что оба адресуемы ссылкой и оба обязаны переживать перезагрузку страницы.

Экраны

Экранов три; описаны все три.

Код	Экран	Когда показывается
Э-01	Запрос выгрузки	Субъект открыл пункт «Выгрузка моих данных»; активной задачи нет
Э-02	Выгрузка готовится	Задача создана и не завершена, либо завершена и ссылка ещё жива
Э-03	Запрос отклонён	Заказ отклонён правилом частоты или неподтверждённой личностью

Э-01 «Запрос выгрузки». Содержит: заголовок раздела; перечень того, что войдёт в архив, — профиль, журнал действий за 730 дней, согласия на рассылки; строку о сроке подготовки до 72 часов; строку о частоте не чаще раза в 30 дней; отметку о подтверждении личности с текущим состоянием; действие «Заказать выгрузку»; действие «Вернуться в настройки».

Э-02 «Выгрузка готовится». Содержит: состояние подготовки словами, без доли выполнения в процентах — доля на стороне интерфейса неизвестна; время создания задачи; предельный срок готовности; действие «Обновить состояние»; действие «Отменить выгрузку»; действие «Вернуться в настройки». После появления ссылки на том же экране появляется действие «Скачать архив» и срок жизни ссылки.

Э-03 «Запрос отклонён». Содержит: причину отказа обычным языком; дату, начиная с которой заказ снова возможен, — для отказа по частоте; действие «Запросить переопределение»; действие «Вернуться в настройки». Для отказа по неподтверждённой личности вместо даты показывается действие «Подтвердить личность».

Пути пользователя и покрытие действий

Покрытие проверяется поимённо: каждое действие каждого экрана названо ниже хотя бы раз (standard/08 §8.5.6 — «покрывающие каждое доступное через интерфейс пользовательское действие»).

Путь	Экраны	Покрытые действия
П-1. Обычный заказ	Э-01 → Э-02	Раскрытие перечня состава архива, «Заказать выгрузку», «Обновить состояние», «Скачать архив»
П-2. Заказ до подтверждения личности	Э-01 → Э-03 → Э-01	«Подтвердить личность»
П-3. Повторный заказ раньше срока	Э-01 → Э-03	«Запросить переопределение»
П-4. Отказ от начатой выгрузки	Э-02 → Э-01	«Отменить выгрузку»
П-5. Выход из раздела	Э-01, Э-02, Э-03	«Вернуться в настройки» с каждого из трёх экранов

Сверка счётом: действий на трёх экранах восемь — раскрытие перечня состава архива, «Заказать выгрузку», «Вернуться в настройки», «Обновить состояние», «Отменить выгрузку», «Скачать архив», «Запросить переопределение», «Подтвердить личность». Все восемь названы в путях П-1…П-5. Непокрытых действий нет.

Сквозные элементы

Права доступа. Все три экрана доступны только владельцу учётной записи. Участник в роли privacy-officer этих экранов не видит и заказать выгрузку за субъекта не может; его интерфейс — вне Scope.

Уведомления. Интерфейс не уведомляет о готовности сам: уведомление уходит почтой. На Э-02 это сказано явно, чтобы субъект не держал вкладку открытой.

Состояния ошибки. Отказ по правилам — это Э-03, полноценный экран. Сбой связи и недоступность службы выгрузки показываются на том экране, где произошли, сообщением с действием «Повторить»; они не переводят на Э-03, потому что заказ не отклонён, а не доставлен.

Пустые состояния. У Э-01 пустого состояния нет — перечень состава непуст всегда. На Э-02 пустое состояние невозможно по построению: экран показывается только при существующей задаче.

Тон и стиль

Обращение на «вы» со строчной буквы. Причина отказа называется прямо и без извинений: «Выгрузка доступна раз в 30 дней. Следующий заказ — с 12 июня». Служебные слова — «задача», «архив», «журнал действий» — не заменяются техническими: job, bundle, activity log на экранах не появляются.

Доступность

Уровень — WCAG-AA. Существенно для этих трёх экранов: смена состояния на Э-02 объявляется программе экранного доступа как живая область, иначе субъект не узнает о готовности архива; причина недоступности действия «Заказать выгрузку» связана с самим действием программно, а не только расположена рядом; отказ на Э-03 не передаётся одним лишь цветом; порядок обхода с клавиатуры совпадает с порядком чтения на всех трёх экранах.

Языковые версии

Обязательны русская и английская. Дата возможного повторного заказа выводится в языковом формате, а не одним видом для обеих версий. Длина строки причины отказа не ограничена шириной кнопки: английская формулировка длиннее русской, и экран обязан переносить её, а не обрезать.

Связь с требованиями

SR-10 — заказ выгрузки через интерфейс (constrained-by). SR-09 — доставка готового архива, интерфейсная часть которой ограничена действием «Скачать архив» на Э-02. BR-02 — деловое требование, из которого оба выведены.

Связь с другими SPEC

SPEC-SEC-03 — правило частоты, роль выдающего переопределение, срок жизни ссылки; интерфейс эти правила показывает, но не определяет. SPEC-API-04 — источник состояний задачи, отображаемых на Э-02.

Verification

TC-090 и TC-091 (§7.5). Доступность проверяется отдельными TC типа accessibility, языковые версии — TC типа i18n; в E8 они не развёрнуты.

---

7.5 Пара ux-TC (§9.6.1)

Двухслойная структура §9.6.1: слой намерения исполняет управляющий агент, слой перцептивной проверки — рецензирующая модель. Обязательное расширение frontmatter — judge.vendor, judge.model, baseline.artifact, baseline.perceptual-diff-threshold. Секции тела — по standard/09 §9.4, включая обязательный «Out of scope».

---
id: TC-090
title: "Субъект заказывает выгрузку и видит экран подготовки"
type: TC
tc-type: ux
automation: { status: automated, set-version: "1.0" }
verifies:
  - id: SR-10
    statement: 1                  # SR-10#1 — «Требование», событийная форма
negative: false
judge: { vendor: google, model: "gemini-2.5-pro" }
baseline:
  artifact: "ai-concepts/baselines/SPEC-UI-02-screen-02.png"
  perceptual-diff-threshold: 0.03
---

Контекст. SR-10, раздел «Требование»: «Когда субъект данных подтверждает запрос … система должна создать задачу выгрузки и перевести пользователя на экран состояния этой задачи». Экран Э-02 по SPEC-UI-02.

Предусловия. Учётная запись субъекта с подтверждённым вторым фактором; активных задач выгрузки нет; прошлая выгрузка была более 30 дней назад. Состояние подготовлено механизмом заполнения данных.

Шаги. Намерение, не селекторы: субъект данных хочет получить архив своих данных после входа в раздел приватности.

Pass-критерий. На отрисованном состоянии виден экран подготовки: состояние названо словами, показаны время создания задачи и предельный срок готовности, доступно действие обновления состояния. Перцептивное расхождение с эталоном не превышает 0.03.

Fail-критерий. Наблюдаемые признаки нарушения: остались на экране запроса; доля выполнения показана в процентах; предельный срок отсутствует либо показан как «неизвестно»; ссылка на скачивание предъявлена до готовности архива; задача создана дважды при одном подтверждении.

Постусловия. Ровно одна задача выгрузки в состоянии подготовки; запись в журнале аудита создана. Задача снимается механизмом очистки после прогона.

Out of scope. Не проверяется доставка готового архива и срок жизни ссылки — покрыто парой TC для SR-09. Не проверяется отказ по правилу частоты — покрыто TC-091. Не проверяется доступность экрана — покрыто TC типа accessibility.

---
id: TC-091
title: "Повторный заказ раньше 30 дней отклонён с названной датой"
type: TC
tc-type: ux
automation: { status: automated, set-version: "1.0" }
verifies:
  - id: SR-10
    statement: 5                  # SR-10#5 — «Поведение», отказ по сроку
negative: true
judge: { vendor: google, model: "gemini-2.5-pro" }
baseline:
  artifact: "ai-concepts/baselines/SPEC-UI-02-screen-03.png"
  perceptual-diff-threshold: 0.03
---

Контекст. SR-10, раздел «Поведение»: «Если с момента прошлой выгрузки прошло менее 30 дней и переопределение не выдано, то система должна отказать в заказе». Экран Э-03 по SPEC-UI-02.

Предусловия. Учётная запись субъекта с подтверждённым вторым фактором; прошлая выгрузка завершена 5 дней назад; переопределение не выдавалось.

Шаги. Субъект данных хочет заказать выгрузку повторно после недавно полученного архива.

Pass-критерий. На отрисованном состоянии виден экран отказа: причина названа обычным языком, указана дата возможного следующего заказа, доступно действие запроса переопределения. Перцептивное расхождение с эталоном не превышает 0.03.

Fail-критерий. Наблюдаемые признаки нарушения: задача выгрузки создана вопреки правилу; отказ показан без даты следующего заказа либо с датой в прошлом; отказ передан только цветом, без текста; отказ показан всплывающим сообщением вместо экрана; действие запроса переопределения отсутствует; причина изложена служебным текстом сбоя.

Постусловия. Новых задач выгрузки нет; в журнале аудита создана запись об отказе.

Out of scope. Не проверяется выдача переопределения участником в роли privacy-officer — его интерфейс вне Scope SPEC-UI-02. Не проверяется отказ по неподтверждённой личности — отдельный TC той же пары форм.

Эталоны. Оба TC сверяются с эталонными изображениями из baseline-images спецификации. Замена эталона проходит механизм утверждения с отметкой [baseline-update] (standard/09 §9.13); автоматическое обновление запрещено, иначе изменившийся интерфейс сам себя объявит верным.

---

7.6 SPEC-UC-01 — сценарий использования (§8.5.12)

Сценарий сшивает SR-10, SPEC-UI-02 и SPEC-API-01; исполнитель — человек, поэтому каждый шаг покрыт ux-TC, а не system-TC в обход интерфейса (standard/09 §9.8).

---
id: SPEC-UC-01
title: "Заказ выгрузки персональных данных субъектом"
type: SPEC-UC
spec-type: SPEC-UC
level: system
role: human
persona: "ADAPT-003 §Persona: субъект данных"
covers: [SR-10, SPEC-UI-02, SPEC-API-01]
entry: SPEC-UI-02
steps:
  - { n: 1, action: "Открывает экран запроса выгрузки", ref: SPEC-UI-02, expects: "Экран Э-01 с формой запроса" }
  - { n: 2, action: "Подтверждает запрос", ref: SR-10#1, expects: "Создана задача выгрузки; переход на Э-02" }
  - { n: 3, action: "Ожидает подготовки", ref: SPEC-UI-02, expects: "Э-02 показывает состояние задачи" }
  - { n: 4, action: "Получает отказ при повторном заказе раньше 30 дней", ref: SR-10#5, expects: "Э-03 с причиной отказа" }
source: { adapt: "ADAPT-003", adapt-section: "Forward §4", tz-section: "§5.2" }
---
## Цель и исполнитель
Субъект данных заказывает выгрузку своих данных и видит состояние задачи.

## Предусловия
Личность подтверждена; предыдущей выгрузки не было либо прошло ≥ 30 дней.

## Основной путь
Шаги 1–3 из frontmatter; каждый ссылается на утверждение `SR-10` или экран `SPEC-UI-02`.

## Альтернативные и негативные ветви
Шаг 4 — отказ по сроку (`SR-10`, «Поведение»); отказ по неподтверждённой личности — вне Scope (см. `SPEC-UI-02`).

## Постусловия
Задача выгрузки существует в состоянии «в подготовке» либо отказ зафиксирован в журнале.

## Покрывающие TC
`TC-090` (шаги 1–3, positive), `TC-091` (шаг 4, negative); оба `tc-type: ux`.

Шаг без ref — нарушение структурной полноты (§8.5.12.1): версия комплекта с таким сценарием не утверждается.

7.7 Что этот пример не доказывает

Отмечено явно, чтобы пример не читался как больше, чем он есть.

• Подъёмность «всех экранов» на реальной системе. Экранов три. На трёх экранах проверена форма обязательного тела, а не его объём. Продукт с полусотней экранов даст другую цену, и она этим примером не измерена.
• Пригодность формы утверждения на накопленном описании. Пять форм §6.6.3.1 применены к пяти утверждениям, написанным сразу по форме. Перевод существующего описания в эти формы — другая задача, и модальность правила остаётся рекомендательной именно поэтому (standard/06 §6.6.3.1).
• Машинная проверка покрытия перечня экранов. Таблица §7.1 сведена вручную; статический TC, сверяющий screens[] всех SPEC-UI с перечнем SPEC-ARCH-01, в примере не написан.
• Работоспособность перцептивной проверки. TC-090 и TC-091 написаны по §9.6.1, но не прогонялись: эталонных изображений в корпусе нет, и рецензирующая модель к примеру не подключалась. Проверено, что поля §9.6.1 заполняются без изобретения новых, — не более.

---

Guide RENAR 1.1 — renar.tech