10 KiB
ADDED Requirements
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.
Scenario: Product Owner формулирует Proposal
- WHEN владелец описывает требуемое изменение, не зная структуры кода и файлов
- THEN Proposal остаётся полноценным утверждаемым намерением без необходимости принимать архитектурные решения
Scenario: Агент подготавливает Tasks
- WHEN Proposal, Delta Specs и Design уже утверждены
- THEN Tasks перечисляет конкретные действия реализации и проверки, но не заявляет будущие результаты уже выполненными
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.
Scenario: Proposal ещё не утверждён
- WHEN AI-агент завершил черновик Proposal, но Change Owner не дал явного согласия
- THEN Delta Specs, Design и Tasks остаются недоступны для создания
Scenario: Delta Specs утверждены
- WHEN Change Owner явно подтверждает Delta Specs после утверждённого Proposal
- THEN Design становится следующим разрешённым planning artifact, а Tasks и Apply остаются заблокированы
Requirement: Изменение upstream artifact требует каскадной проверки
Изменение утверждённого Proposal MUST инициировать повторную проверку Delta Specs, Design и Tasks; изменение утверждённых Delta Specs MUST инициировать повторную проверку Design и Tasks; изменение утверждённого Design MUST инициировать повторную проверку Tasks. Изменение Tasks MUST NOT неявно менять scope, наблюдаемое поведение или архитектурные решения upstream artifacts; при таком обнаружении workflow SHALL вернуть работу к соответствующему upstream artifact и его approval gate.
Scenario: После Design изменилось намерение
- WHEN владелец меняет scope или ожидаемый эффект Proposal
- THEN зависимые Delta Specs, Design и Tasks теряют прежнее подтверждение до повторной согласованной проверки
Scenario: Task вводит новое поведение
- WHEN implementation checklist требует поведение, которого нет в утверждённых Delta Specs
- THEN агент не расширяет scope через Tasks и возвращает change к Delta Specs
Requirement: OpenSpec tooling имеет проверяемый version contract
SDD workflow MUST объявлять поддерживаемую версию OpenSpec CLI и проверять фактическую версию до команд, читающих или изменяющих canonical change. Несовместимая либо неопределённая версия MUST давать actionable blocking result и MUST NOT приводить к молчаливому изменению artifact graph, templates или project-owned entrypoints.
Scenario: Версия CLI соответствует контракту
- WHEN агент начинает работу с canonical change поддерживаемой версией OpenSpec
- THEN workflow продолжает работу с объявленной схемой и canonical store
Scenario: Версия CLI не соответствует контракту
- WHEN доступная версия OpenSpec не совпадает с объявленным совместимым контрактом
- THEN локальная preflight-проверка блокирует SDD-операцию и сообщает ожидаемую и фактическую версии
Requirement: Structural и semantic verification являются разными gates
OpenSpec structural validation SHALL проверять schema, artifact graph и формальную корректность specs, но MUST NOT считаться доказательством соответствия реализации. До terminal status change MUST пройти semantic verification реализации против Proposal, Delta Specs, Design и Tasks, а затем независимый read-only review. Если основной agent entrypoint semantic verification недоступен, workflow SHALL использовать versioned эквивалентную процедуру с теми же входными артефактами, категориями проверки и наблюдаемым evidence.
Scenario: Structural validation прошла без ошибок
- WHEN все planning artifacts формально валидны, но реализация ещё не сопоставлена с ними
- THEN change не получает terminal status только на основании structural validation
Scenario: Slash workflow недоступен агенту
- WHEN среда не предоставляет установленный semantic verification entrypoint
- THEN агент выполняет документированную эквивалентную read-only проверку и сохраняет её результат вместо пропуска gate
MODIFIED Requirements
Requirement: Archive блокируется незавершёнными tasks
Project-owned archive workflow MUST отклонять archive, если отсутствует требуемый planning artifact, любой обязательный artifact не утверждён, tasks.md отсутствует или содержит unchecked task, semantic verification либо независимый read-only review не завершены успешно, или любая affected delivery area не реализована и не прошла обязательные pre-archive gates. Workflow MUST NOT предлагать confirmation override для этих blocking conditions. Post-archive bookkeeping MUST NOT появляться как unchecked task; он SHALL фиксироваться через детерминированное Completion Evidence после успешного archive, после чего связанная delivery может получить terminal status.
Scenario: Change имеет unchecked task
- WHEN implementer запрашивает archive и остаётся хотя бы один unchecked task
- THEN workflow не архивирует change и сообщает incomplete tasks как blocking condition без возможности confirmation override
Scenario: Change не прошёл required verification
- WHEN planning artifacts и tasks завершены, но semantic verification, independent review, implementation или pre-archive gate affected area отсутствуют либо неуспешны
- THEN workflow не архивирует change и перечисляет недостающие blocking conditions
Scenario: Change завершил все tasks
- WHEN каждый planning artifact утверждён, каждый task отмечен, required verification, implementation и pre-archive gates всех affected areas успешно завершены
- THEN workflow допускает archive, после которого его результат фиксируется через определённый completion-evidence path без создания post-archive task