chore: harden SDD governance workflow

This commit is contained in:
2026-08-24 19:55:28 +03:00
parent 20295190dd
commit 0006aea562
30 changed files with 1659 additions and 75 deletions
@@ -0,0 +1,61 @@
## Purpose
Определяет полную поставку одного SDD-изменения через независимые frontend, backend, specs и docs репозитории без потерянных областей, фиктивных коммитов и преждевременного статуса done.
## ADDED Requirements
### Requirement: Каждый change содержит полный Delivery Map
Каждый versioned change MUST оценивать delivery areas `frontend`, `backend`, `specs` и `docs` и для каждой области указывать `affected` либо `N/A` с конкретной причиной. `specs` SHALL быть affected для каждого versioned SDD change. `docs` SHALL быть affected для каждой поставленной пользовательской фичи; для технического или процессного change она MAY быть `N/A` только когда фактическая устойчивая документация не изменяется. `frontend` и `backend` SHALL быть affected только когда меняется их поведение, контракт, реализация или обязательный локальный gate. Пустой коммит MUST NOT использоваться для имитации участия незатронутого репозитория.
#### Scenario: Фича затрагивает клиент и API
- **WHEN** change меняет пользовательский поток и соответствующее API-поведение
- **THEN** Delivery Map отмечает frontend, backend, specs и docs как affected и описывает ожидаемый результат каждой области без реализации по файлам
#### Scenario: Область не затронута
- **WHEN** поведение, контракт, реализация, guardrails и фактическая документация области не меняются
- **THEN** Delivery Map содержит проверяемую причину `N/A`, а delivery не требует пустого коммита этого репозитория
### Requirement: Частичная multi-repository delivery не считается завершённой
Change MUST оставаться active, пока каждая affected область не реализована и не прошла свои обязательные локальные gates. Успех одной области MUST NOT позволять архивировать change, если другая affected область отсутствует, не проверена либо не соответствует согласованному поведению. После archive change MUST NOT получить terminal status `done`, пока фактические результаты всех четырёх delivery areas не представлены в Completion Evidence.
#### Scenario: Backend готов, а frontend ещё не реализован
- **WHEN** Delivery Map помечает frontend и backend как affected, но завершён и проверен только backend
- **THEN** change остаётся active и не может быть архивирован
#### Scenario: Все affected области готовы
- **WHEN** каждая affected область реализована, согласована по общим контрактам и прошла требуемые локальные gates
- **THEN** change может перейти к семантической верификации и archive, после которого формируется Completion Evidence для terminal status
### Requirement: Completion Evidence содержит только наблюдённые результаты
Completion Evidence MUST создаваться после выполнения работы и MUST связывать canonical change с commit identifier каждого изменённого Git-репозитория, точными выполненными non-mutating verification commands и их наблюдёнными результатами. Для каждой области с `N/A` evidence SHALL сохранять согласованную причину отсутствия изменения. Planned commands, ожидаемые результаты, незавершённые checklist items и предполагаемые commit identifiers MUST NOT представляться как completion evidence.
#### Scenario: Change готовится к terminal status
- **WHEN** implementer заявляет, что multi-repository change завершён
- **THEN** reviewer может сопоставить Delivery Map с фактическими commits, результатами gates и причинами `N/A` для всех четырёх областей
#### Scenario: Команда ещё не была выполнена
- **WHEN** verification command только запланирована или её результат не сохранён
- **THEN** она остаётся implementation checklist item и не засчитывается как Completion Evidence
### Requirement: Общий локальный verifier сохраняет gates репозиториев
Workspace SHALL предоставлять один non-mutating локальный verification entrypoint для multi-repository delivery. Он MUST проверять совместимость runtime до application gates, запускать канонический gate каждой selected affected области и сохранять их ошибки как blocking result. Общий verifier MUST NOT заменять или ослаблять локальные gates независимых репозиториев.
#### Scenario: Запущен неподдерживаемый runtime
- **WHEN** multi-repository verifier запускается с runtime, не соответствующим объявленному проектом контракту
- **THEN** проверка завершается ошибкой до получения вводящего в заблуждение результата application tests
#### Scenario: Один repository gate завершается ошибкой
- **WHEN** общий verifier проверяет несколько affected областей и канонический gate одной из них не проходит
- **THEN** общий результат является неуспешным и явно указывает failing area без обхода её локального gate