Archive verified session-oriented SDD v2 delivery
This commit is contained in:
@@ -9,12 +9,13 @@
|
||||
|
||||
### Requirement: Каждая agent-сессия имеет одну SDD-роль
|
||||
|
||||
Session-oriented SDD workflow SHALL направлять каждую новую agent-сессию ровно
|
||||
в одну роль: Discovery, Specification, Implementation, Validation или
|
||||
Finalization. Сессия MUST завершаться после результата своей роли и MUST NOT
|
||||
самостоятельно выполнять следующую роль. Когда роль Specification готовит
|
||||
planning artifact, она MUST соблюдать canonical OpenSpec artifact graph и
|
||||
explicit approval boundary.
|
||||
Session-oriented SDD workflow SHALL направлять каждую agent-сессию ровно в одну
|
||||
роль: Discovery, Specification, Implementation, Validation или Finalization.
|
||||
Сессия MUST NOT самостоятельно выполнять следующую роль, но создание immutable
|
||||
phase record или ожидание решения MUST NOT само по себе принуждать к новой
|
||||
сессии той же роли. Specification MUST поддерживать bounded progression
|
||||
`Proposal + Delta Specs` и `Design + Tasks`, сохраняя отдельную explicit
|
||||
approval boundary перед каждым downstream artifact.
|
||||
|
||||
#### Scenario: Начинается новый change
|
||||
|
||||
@@ -22,104 +23,233 @@ explicit approval boundary.
|
||||
- **THEN** workflow направляет сессию только в Discovery и не начинает
|
||||
Specification, Implementation, Validation или Finalization в той же сессии
|
||||
|
||||
#### Scenario: Завершилась реализация
|
||||
|
||||
- **WHEN** Implementation завершает разрешённый scope работы
|
||||
- **THEN** workflow фиксирует результат Implementation как вход для следующей
|
||||
сессии, направляет продолжение в Validation и не выполняет Validation в
|
||||
завершившейся Implementation-сессии
|
||||
|
||||
#### Scenario: Specification подготавливает planning artifact
|
||||
|
||||
- **WHEN** Specification готовит следующий OpenSpec planning artifact
|
||||
- **THEN** workflow создаёт только artifact, разрешённый текущей approval
|
||||
boundary, и останавливается до явного решения Change Owner
|
||||
- **WHEN** Specification подготовила structurally valid Proposal
|
||||
- **THEN** workflow запрашивает явный approval Change Owner и не создаёт Delta
|
||||
Specs до получения решения
|
||||
|
||||
#### Scenario: Proposal явно одобрен
|
||||
|
||||
- **WHEN** Change Owner явно одобряет неизменившийся Proposal в bounded
|
||||
`Proposal + Delta Specs` progression
|
||||
- **THEN** Specification MAY продолжить в той же роли и создать Delta Specs без
|
||||
перехода к Design или другой SDD-роли
|
||||
|
||||
#### Scenario: Delta Specs явно одобрены
|
||||
|
||||
- **WHEN** Change Owner явно одобряет неизменившиеся Delta Specs
|
||||
- **THEN** workflow завершает bounded `Proposal + Delta Specs` progression и
|
||||
направляет следующий Specification outcome к Design
|
||||
|
||||
#### Scenario: Design явно одобрен
|
||||
|
||||
- **WHEN** Change Owner явно одобряет неизменившийся Design в bounded
|
||||
`Design + Tasks` progression
|
||||
- **THEN** Specification MAY продолжить в той же роли и создать Tasks без
|
||||
перехода к Implementation до отдельного approval Tasks
|
||||
|
||||
#### Scenario: Завершилась реализация
|
||||
|
||||
- **WHEN** Implementation завершает все утверждённые implementation-owned Tasks
|
||||
- **THEN** workflow фиксирует результат Implementation как вход для следующей
|
||||
Validation-сессии и не выполняет Validation в завершившейся
|
||||
Implementation-сессии
|
||||
|
||||
### Requirement: Продолжение workflow восстанавливает только нужный контекст
|
||||
|
||||
Workflow SHALL определять следующую роль из сохранённого состояния change и
|
||||
минимального handoff предыдущей роли. Он MUST загружать phase-specific canonical
|
||||
authority, а не полную историю предыдущих сессий или все прежние handoff-данные.
|
||||
После появления OpenSpec change его approved artifacts MUST быть источником
|
||||
требований для последующих ролей; handoff MAY передавать только навигационные
|
||||
факты, результаты и нерешённые блокеры.
|
||||
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.
|
||||
|
||||
#### Scenario: Пользователь продолжает change после другой сессии
|
||||
|
||||
- **WHEN** пользователь запрашивает продолжение известного change
|
||||
- **THEN** workflow определяет следующую разрешённую роль из сохранённого
|
||||
состояния и загружает текущий handoff и применимую canonical authority этой
|
||||
роли
|
||||
- **THEN** workflow определяет ровно одну текущую роль, читает только актуальный
|
||||
handoff и применимую canonical authority этой роли
|
||||
|
||||
#### Scenario: Есть история нескольких попыток
|
||||
|
||||
- **WHEN** change содержит предыдущие handoff-данные или результаты ранних
|
||||
попыток
|
||||
- **THEN** workflow не загружает их по умолчанию и обращается к ним только при
|
||||
необходимости расследовать проблему текущей роли
|
||||
- **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
|
||||
без причины
|
||||
|
||||
### Requirement: Handoff не заменяет canonical OpenSpec authority
|
||||
|
||||
Workflow handoff SHALL сохранять только состояние перехода между ролями,
|
||||
краткий результат, известные блокеры и один следующий допустимый outcome. Handoff
|
||||
MUST NOT становиться альтернативным хранилищем Requirements, Delta Specs,
|
||||
Design, Tasks, acceptance scenarios или approval decisions.
|
||||
Workflow handoff SHALL сохранять только состояние перехода, краткий observed
|
||||
result, известные блокеры и один следующий допустимый outcome. Navigation state
|
||||
MAY сохранять approval status текущих planning artifacts для продолжения
|
||||
workflow, но handoff и state MUST NOT становиться альтернативным хранилищем
|
||||
Requirements, Delta Specs, Design, Tasks или acceptance scenarios и MUST NOT
|
||||
считаться самостоятельным доказательством решения Change Owner.
|
||||
|
||||
#### Scenario: Specification уже завершена
|
||||
|
||||
- **WHEN** следующая роль получает handoff после Specification
|
||||
- **THEN** она использует OpenSpec artifacts для требований и технических
|
||||
решений, а handoff использует только для маршрутизации и известных ограничений
|
||||
- **THEN** она использует approved OpenSpec artifacts для требований и решений,
|
||||
а handoff — только для маршрутизации, observed results и известных
|
||||
ограничений
|
||||
|
||||
#### Scenario: Approval подтверждён для неизменившегося artifact
|
||||
|
||||
- **WHEN** новый Specification context содержит сохранённый approved status и
|
||||
workflow не изменял соответствующий planning artifact
|
||||
- **THEN** workflow продолжает к разрешённому downstream artifact без
|
||||
повторного запроса того же approval
|
||||
|
||||
#### Scenario: Workflow изменяет planning artifact
|
||||
|
||||
- **WHEN** workflow семантически изменяет planning artifact
|
||||
- **THEN** approval этого artifact и всех зависимых downstream artifacts
|
||||
сбрасывается до нового явного решения Change Owner
|
||||
|
||||
#### Scenario: Требование нужно изменить во время реализации
|
||||
|
||||
- **WHEN** Implementation обнаруживает, что requirement или архитектурное
|
||||
решение неполно либо противоречиво
|
||||
- **THEN** workflow возвращает работу к соответствующей canonical planning
|
||||
boundary и не изменяет требование только в handoff или реализации
|
||||
- **THEN** workflow возвращает работу к самой ранней затронутой canonical
|
||||
planning boundary и не изменяет требование только в handoff или реализации
|
||||
|
||||
### Requirement: Validation остаётся независимой и без побочных исправлений
|
||||
|
||||
Validation SHALL независимо сопоставлять canonical OpenSpec artifacts с
|
||||
состоянием репозитория, релевантными проверками и наблюдаемым поведением. Она
|
||||
MUST NOT изменять production implementation или спецификацию. Validation MUST
|
||||
возвращать PASS, FAIL либо SPEC_ISSUE и направлять следующую сессию к
|
||||
Finalization, Implementation либо соответствующей planning boundary.
|
||||
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.
|
||||
|
||||
#### Scenario: Реализация соответствует утверждённому change
|
||||
|
||||
- **WHEN** Validation подтверждает requirements, relevant checks и границы
|
||||
scope без blocking findings
|
||||
- **WHEN** Validation подтверждает approved requirements, affected gates,
|
||||
acceptance behavior и отсутствие blocking review findings
|
||||
- **THEN** она возвращает PASS и разрешает следующую сессию Finalization
|
||||
|
||||
#### Scenario: Найдена проблема реализации
|
||||
|
||||
- **WHEN** Validation находит несоответствие реализации утверждённому OpenSpec
|
||||
- **THEN** она возвращает FAIL с наблюдаемым finding и направляет следующую
|
||||
- **THEN** она возвращает FAIL с точным observed finding и направляет следующую
|
||||
сессию к Implementation без самостоятельного исправления
|
||||
|
||||
#### Scenario: Найдена проблема спецификации
|
||||
|
||||
- **WHEN** Validation находит противоречие или пробел в canonical planning
|
||||
- **WHEN** Validation находит противоречие или пробел в approved planning
|
||||
artifacts
|
||||
- **THEN** она возвращает SPEC_ISSUE и направляет работу к самой ранней
|
||||
затронутой planning boundary без переписывания specification под реализацию
|
||||
|
||||
#### Scenario: Tasks планируют независимую проверку
|
||||
|
||||
- **WHEN** Tasks описывают ожидаемую semantic verification или independent
|
||||
review после реализации
|
||||
- **THEN** завершение Implementation не зависит от checkbox, который может
|
||||
закрыть только Validation
|
||||
|
||||
### Requirement: Finalization требует успешной независимой Validation
|
||||
|
||||
Workflow SHALL разрешать Finalization только после последней независимой
|
||||
Validation с результатом PASS. Если Finalization обнаруживает failure обязательной
|
||||
проверки или проблему корректности, она MUST сообщить блокировку и направить
|
||||
работу к ответственной предыдущей роли, не исправляя реализацию самостоятельно.
|
||||
Validation с PASS, если после неё не было relevant изменений planning или
|
||||
delivery inputs. Finalization MUST выполнять только archive и completion
|
||||
mechanics, MUST NOT повторять актуальную Validation и MUST направлять каждый
|
||||
blocker к точной ответственной роли без исправления production implementation
|
||||
или planning artifacts.
|
||||
|
||||
#### Scenario: Последняя Validation прошла
|
||||
|
||||
- **WHEN** Finalization получает change после последнего PASS Validation
|
||||
- **THEN** она выполняет только допустимые действия завершения canonical
|
||||
lifecycle и фиксирует результат завершения
|
||||
- **WHEN** Finalization получает change после PASS и relevant inputs с момента
|
||||
этой Validation не изменялись
|
||||
- **THEN** она использует observed PASS и выполняет completion mechanics без
|
||||
повторной independent Validation
|
||||
|
||||
#### Scenario: Implementation-owned Task не завершена
|
||||
|
||||
- **WHEN** Finalization обнаруживает незавершённую implementation-owned Task
|
||||
- **THEN** она возвращает blocker в Implementation и не архивирует change
|
||||
|
||||
#### Scenario: PASS отсутствует или устарел
|
||||
|
||||
- **WHEN** последняя Validation не завершилась PASS либо после PASS изменились
|
||||
relevant planning или delivery inputs
|
||||
- **THEN** Finalization возвращает blocker в Validation и не считает прежний
|
||||
outcome актуальным
|
||||
|
||||
#### Scenario: Обнаружена planning issue
|
||||
|
||||
- **WHEN** Finalization обнаруживает противоречие или пробел в approved planning
|
||||
artifacts
|
||||
- **THEN** она возвращает blocker к самой ранней затронутой Specification
|
||||
boundary без самостоятельного исправления
|
||||
|
||||
#### Scenario: Completion mechanics временно недоступны
|
||||
|
||||
- **WHEN** production и planning inputs корректны, но собственное retryable
|
||||
действие завершения не выполнено из-за environment или completion failure
|
||||
- **THEN** workflow остаётся в Finalization с observed blocker и не повторяет
|
||||
Implementation или Validation без изменения их inputs
|
||||
|
||||
#### Scenario: В Finalization обнаружена проблема
|
||||
|
||||
- **WHEN** Finalization обнаруживает failed check или проблему корректности
|
||||
- **THEN** она возвращает блокировку с наблюдаемой причиной и не закрывает
|
||||
lifecycle change до работы ответственной роли
|
||||
- **WHEN** Finalization обнаруживает любой blocker завершения
|
||||
- **THEN** она не закрывает lifecycle change, сохраняет observed cause и
|
||||
направляет продолжение к точной ответственной роли
|
||||
|
||||
### Requirement: Implementation сохраняет ограниченные checkpoints
|
||||
|
||||
Implementation SHALL выбирать связный ограниченный batch из оставшихся
|
||||
утверждённых Tasks и MAY завершить сессию, оставаясь в роли Implementation,
|
||||
если весь change ещё не реализован. Такой checkpoint MUST фиксировать
|
||||
завершённые canonical Tasks, оставшуюся работу и достаточный результат
|
||||
релевантных проверок, не выдавая неполный change за готовый к Validation.
|
||||
|
||||
#### Scenario: Завершён один связный batch
|
||||
|
||||
- **WHEN** Implementation завершила и проверила ограниченный batch, но в
|
||||
canonical Tasks осталась implementation-owned работа
|
||||
- **THEN** workflow сохраняет завершённые и оставшиеся Tasks, направляет
|
||||
продолжение в новую Implementation-сессию и не сообщает blocker или
|
||||
готовность к Validation
|
||||
|
||||
#### Scenario: Завершена вся implementation-owned работа
|
||||
|
||||
- **WHEN** все утверждённые implementation-owned Tasks выполнены и релевантные
|
||||
проверки Implementation успешны
|
||||
- **THEN** workflow фиксирует готовность change к независимой Validation
|
||||
|
||||
### Requirement: Активные инструкции согласованы и независимы от agent runtime
|
||||
|
||||
Активные SDD и repository instructions SHALL направлять участника к одной
|
||||
authority для общей lifecycle policy и одной authority для операционной context
|
||||
discipline. Они MUST сохранять одинаковые approval и completion safeguards и
|
||||
MUST NOT требовать конкретный AI-agent runtime или его необязательные
|
||||
framework-specific entrypoints для выполнения canonical workflow.
|
||||
|
||||
#### Scenario: Участник начинает работу из любого active entrypoint
|
||||
|
||||
- **WHEN** участник открывает root или repository-local active instructions
|
||||
- **THEN** он получает согласованный canonical lifecycle, применимые локальные
|
||||
boundaries и ссылки на общую authority без противоречащей копии shared policy
|
||||
|
||||
#### Scenario: Необязательный agent runtime отсутствует
|
||||
|
||||
- **WHEN** участник выполняет workflow без vendor-specific commands, skills или
|
||||
instruction tree
|
||||
- **THEN** все canonical planning, implementation, validation и finalization
|
||||
outcomes остаются достижимыми без ослабления safeguards
|
||||
|
||||
@@ -8,17 +8,34 @@
|
||||
|
||||
### Requirement: Completion Evidence сохраняет фактическое завершение change
|
||||
|
||||
Durable development documentation SHALL хранить для завершённого change ссылку на canonical OpenSpec archive, Delivery Map, commit identifiers изменённых репозиториев, точные выполненные verification commands, их наблюдённые результаты и итог independent read-only review. Completion Evidence MUST создаваться из фактов после выполнения работы, MUST быть доступно из устойчивого index или registry и MUST NOT дублироваться как unchecked task либо планируемый результат внутри archived change.
|
||||
Canonical archived OpenSpec change SHALL хранить Completion Evidence с
|
||||
фактической Delivery Map, commit identifiers изменённых delivery areas, точными
|
||||
выполненными verification commands и их observed results, а также итогом
|
||||
independent read-only review. Completion Evidence MUST создаваться только после
|
||||
существования этих фактов, MUST быть доступно вместе с canonical archive и MUST
|
||||
NOT представляться как unchecked Task, планируемый результат или обязательная
|
||||
docs-мутация для area со статусом `N/A`.
|
||||
|
||||
#### Scenario: Участник проверяет основание terminal status
|
||||
|
||||
- **WHEN** участник открывает evidence завершённого change в новой сессии
|
||||
- **THEN** он может проследить связь от change и Delivery Map к фактическим commits, локальным gates и independent review без восстановления контекста из чата
|
||||
- **WHEN** участник открывает canonical archive завершённого change в новой
|
||||
сессии
|
||||
- **THEN** он может проследить связь от Delivery Map к фактическим commits,
|
||||
affected local gates и independent review без восстановления контекста из
|
||||
чата или параллельного evidence store
|
||||
|
||||
#### Scenario: Реализация ещё продолжается
|
||||
|
||||
- **WHEN** часть commands, commits или review ещё не существует
|
||||
- **THEN** documentation не представляет ожидаемые значения как Completion Evidence и change остаётся незавершённым
|
||||
- **WHEN** часть delivery commits, commands, observed results или review ещё не
|
||||
существует
|
||||
- **THEN** change не представляет ожидаемые значения как Completion Evidence и
|
||||
не получает terminal status
|
||||
|
||||
#### Scenario: Технический change не меняет as-built documentation
|
||||
|
||||
- **WHEN** фактическая Delivery Map обоснованно устанавливает `docs: N/A`
|
||||
- **THEN** Completion Evidence сохраняет эту причину рядом с canonical archive
|
||||
и не требует несвязанного изменения docs repository
|
||||
|
||||
### Requirement: Важные архитектурные решения фиксируются в ADR
|
||||
Репозиторий docs SHALL содержать ADR для выбора локального хранилища, API-контракта, gRPC-интеграции T-Bank, хранения T-Bank токенов, устойчивости upstream-вызовов, auth-сессий и frontend-кэша. Каждый ADR MUST описывать контекст, решение и последствия.
|
||||
@@ -35,37 +52,91 @@ Durable development documentation SHALL хранить для завершённ
|
||||
- **THEN** ее feature-документ существует и отражает фактическое поведение
|
||||
|
||||
### Requirement: OpenSpec change закрывается только после полной верификации
|
||||
Функциональный OpenSpec change MUST содержать все требуемые артефакты, реализацию, критические тесты, успешную проверку `opsx-verify` и связанную документацию до архивирования.
|
||||
|
||||
OpenSpec change MUST содержать все обязательные planning artifacts и
|
||||
завершённые implementation-owned Tasks до архивирования. Archive MUST быть
|
||||
заблокирован, пока отсутствует успешный canonical gate любой affected area,
|
||||
semantic и acceptance verification реализации относительно approved artifacts
|
||||
либо independent read-only review без Critical и Important findings; для area
|
||||
со статусом `N/A` MUST существовать конкретная проверяемая причина.
|
||||
|
||||
#### Scenario: Команда пытается архивировать незавершенное изменение
|
||||
- **WHEN** для изменения отсутствует реализация, верификация или feature-документ
|
||||
- **THEN** изменение не считается готовым к архивированию
|
||||
|
||||
- **WHEN** для change отсутствует обязательный artifact, implementation-owned
|
||||
результат, affected-area gate, semantic или acceptance verification,
|
||||
допустимый independent review либо требуемая as-built documentation
|
||||
- **THEN** change не архивируется и остаётся незавершённым без confirmation
|
||||
override
|
||||
|
||||
#### Scenario: Delivery area не затронута
|
||||
|
||||
- **WHEN** Delivery Map помечает area как `N/A`
|
||||
- **THEN** archive допускает отсутствие её commit и gate только при наличии
|
||||
конкретной проверяемой причины
|
||||
|
||||
### Requirement: Документация процесса содержит remediation registry
|
||||
Репозиторий `docs` SHALL содержать immutable versioned audit snapshots в `docs/audits` и versioned remediation registry в разделе development documentation. Registry MUST документировать source audit, допустимые статусы, связанные OpenSpec changes, следующую рекомендуемую задачу и evidence завершённых remediation changes.
|
||||
|
||||
Репозиторий `docs` SHALL содержать immutable versioned audit snapshots в
|
||||
`docs/audits` и versioned remediation registry в development documentation.
|
||||
Registry MUST документировать source audit, допустимые статусы, связанные
|
||||
OpenSpec changes и следующую рекомендуемую задачу. Для завершённого
|
||||
audit-derived change registry MUST ссылаться на canonical archive и его
|
||||
Completion Evidence, а не дублировать commits и verification results как
|
||||
отдельный evidence store.
|
||||
|
||||
#### Scenario: Участник проекта ищет состояние технических улучшений
|
||||
|
||||
- **WHEN** участник открывает development documentation
|
||||
- **THEN** он может найти audit snapshot и registry через documentation indexes и определить, какие findings planned, active, done, deferred или accepted
|
||||
- **THEN** он может найти audit snapshot и registry через documentation indexes
|
||||
и определить, какие findings planned, active, done, deferred или accepted
|
||||
|
||||
#### Scenario: Завершён audit-derived change
|
||||
- **WHEN** связанный OpenSpec change архивирован после успешной проверки
|
||||
- **THEN** registry обновляется с archive path, commits затронутых репозиториев и результатами exact verification commands
|
||||
|
||||
- **WHEN** связанный OpenSpec change получил terminal status после успешной
|
||||
проверки
|
||||
- **THEN** registry содержит его итоговый статус и ссылку на canonical archive
|
||||
с Completion Evidence
|
||||
|
||||
### Requirement: Durable documentation is not a parallel SDD store
|
||||
Репозиторий `docs` SHALL хранить только долговечную architecture, development, feature, audit и remediation documentation вместе с completion evidence. Документация MUST описывать фактическое текущее состояние поставленной системы и MUST NOT представлять планируемое или частично реализованное поведение как доступное. Change-specific requirements, proposals, designs, delta specifications и tasks MUST храниться только в canonical OpenSpec store и MUST NOT пересказываться в `docs` как параллельная спецификация в другом формате. Docs SHALL обновляться после реализации и проверки соответствующей области; она MAY ссылаться на canonical OpenSpec change, но MUST сохранять собственную as-built задачу и не копировать его нормативный текст.
|
||||
|
||||
Репозиторий `docs` SHALL хранить только долговечную architecture, development,
|
||||
feature, audit и remediation documentation. Документация MUST описывать
|
||||
фактическое текущее состояние поставленной системы и MUST NOT представлять
|
||||
планируемое или частично реализованное поведение как доступное. Change-specific
|
||||
requirements, proposals, designs, delta specifications, tasks и Completion
|
||||
Evidence MUST храниться только в canonical OpenSpec store и MUST NOT
|
||||
пересказываться в `docs` как параллельная спецификация или evidence store. Docs
|
||||
SHALL обновляться после реализации и проверки только когда её as-built subject
|
||||
действительно affected.
|
||||
|
||||
#### Scenario: Change требует постоянной документации
|
||||
- **WHEN** завершённый change должен оставить устойчивое объяснение решения или evidence
|
||||
- **THEN** documentation фиксирует реализованное состояние или completion evidence и ссылается на canonical OpenSpec change без дублирования его requirements, design или tasks
|
||||
|
||||
- **WHEN** завершённый change меняет поставленное поведение, архитектурную
|
||||
границу, устойчивое решение или другой as-built subject docs
|
||||
- **THEN** documentation фиксирует реализованное состояние и MAY ссылаться на
|
||||
canonical OpenSpec change без дублирования его planning artifacts или
|
||||
Completion Evidence
|
||||
|
||||
#### Scenario: Agent планирует незавершённый change
|
||||
- **WHEN** агент создаёт requirements, design или tasks для незавершённого изменения
|
||||
- **THEN** он сохраняет их под `specs/openspec` и не создаёт framework-specific planning document или описание будущего поведения в `docs`
|
||||
|
||||
- **WHEN** агент создаёт requirements, design или tasks для незавершённого
|
||||
изменения
|
||||
- **THEN** он сохраняет их в canonical OpenSpec store и не создаёт
|
||||
framework-specific planning document или описание будущего поведения в docs
|
||||
|
||||
#### Scenario: Реализация расходится с прежней документацией
|
||||
- **WHEN** проверенный change изменяет поставленное поведение, архитектурную границу или устойчивое решение
|
||||
- **THEN** affected docs обновляется до фактического текущего состояния до terminal status и не сохраняет прежнее утверждение как действующее
|
||||
|
||||
- **WHEN** проверенный change изменяет поставленное поведение, архитектурную
|
||||
границу или устойчивое решение
|
||||
- **THEN** affected docs обновляется до фактического текущего состояния до
|
||||
terminal status и не сохраняет прежнее утверждение как действующее
|
||||
|
||||
#### Scenario: Docs не входит в Delivery Map
|
||||
|
||||
- **WHEN** технический change не меняет ни один as-built subject docs и Delivery
|
||||
Map устанавливает `docs: N/A` с проверяемой причиной
|
||||
- **THEN** terminal status не требует изменения docs только ради Completion
|
||||
Evidence
|
||||
|
||||
### Requirement: Устойчивая документация имеет доступные фактические точки входа
|
||||
Репозиторий `docs` SHALL содержать indexes архитектуры, разработки и фич,
|
||||
|
||||
Reference in New Issue
Block a user