20 KiB
MODIFIED Requirements
Requirement: Agent context следует текущей SDD-фазе
Project-owned agent workflow SHALL начинать каждую работу с определения текущей SDD-фазы и affected delivery areas, а затем SHALL загружать canonical artifacts, локальные routing instructions и supporting authority, применимые к этой фазе и этим areas. Переход в новую agent-сессию после утверждения planning artifact SHALL использовать canonical artifact и явное решение Change Owner как основание продолжения. Workflow MUST NOT требовать полную историю предыдущей сессии или отдельный handoff/context artifact, дублирующий OpenSpec authority. Supporting material, не влияющий на текущую фазу, затронутую область, доменную семантику или обязательный gate, SHALL загружаться только при появлении наблюдаемой необходимости.
Workflow SHALL проверять применимость контекста до первого зависимого решения, при обнаружении новой области или границы и перед handoff по фактическому scope, включая staged, unstaged и новые файлы. Проверка SHALL учитывать содержание изменения, а не только первоначальное описание задачи или наличие staging. Обнаружение нового scope MUST NOT разрешать выход за утверждённые planning boundaries: требующее пересмотра intent, behavior, architecture или Tasks расширение SHALL возвращаться к самой ранней затронутой boundary до зависимой работы.
Workflow MUST получать все возвращённые native contextFiles, применимые risk inputs и согласованный Design package текущей фазы независимо от количества документов. Это правило SHALL действовать и при recovery; уже прочитанные неизменившиеся inputs в том же контексте MAY переиспользоваться по существующей context discipline. Недоступный обязательный input MUST оставаться явным блокером зависимого решения, а не заменяться историей чата или догадкой. Маршрутизация MUST опираться на существующую context authority и MUST NOT вводить параллельный workflow, scoring, числовой token gate или лимит числа обязательных документов.
Scenario: Утверждённый artifact передаётся в новую сессию
- WHEN Change Owner явно утверждает текущий planning artifact и следующая agent-сессия продолжает change на разрешённой downstream-фазе
- THEN workflow восстанавливает работу из canonical change artifacts, owner approval и применимых routing instructions без обязательной передачи полной истории обсуждения или создания второго handoff artifact
Scenario: Работа ограничена одной delivery area
- WHEN текущая фаза затрагивает одну определённую delivery area и не требует cross-system или доменной оценки
- THEN workflow загружает authority и локальные instructions этой area, а нерелевантные architecture, domain и repository materials остаются lazy context
Scenario: Supporting material становится необходимым
- WHEN во время работы возникает вопрос, влияющий на domain semantics, cross-area architecture, audit disposition или обязательный gate
- THEN workflow загружает соответствующий authoritative material до принятия решения и не использует token-efficiency guidance как основание пропустить требуемый контекст
Scenario: Предстоит первое зависимое решение
- WHEN агент определил фазу и affected areas и готовится принять первое решение, зависящее от локальных правил или иной authority
- THEN он определяет применимые inputs по содержанию задачи и получает их до этого решения, даже если работа ещё не создала diff
Scenario: В пределах approved scope обнаружена новая граница
- WHEN текущая работа выявляет ранее неучтённую границу, уже разрешённую утверждёнными planning artifacts
- THEN workflow пересматривает применимость контекста и получает недостающие правила этой границы до зависимой работы, не требуя нового approval только из-за уточнения набора чтения
Scenario: Новая область требует расширения approved scope
- WHEN обнаруженная область требует изменения утверждённого intent, behavior, architecture или checklist
- THEN workflow загружает применимый контекст для оценки расхождения, сообщает основание возврата к самой ранней затронутой planning boundary и не начинает зависимую работу до требуемого approval
Scenario: Перед handoff есть изменения вне staged diff
- WHEN агент готовит handoff, а unstaged или новые файлы выявляют применимую область или правило, отсутствующие в первоначальном scope
- THEN workflow учитывает их вместе со staged изменениями, пересматривает обязательный контекст и передаёт фактический scope и оставшиеся blockers; отсутствие staging не позволяет пропустить эту область
Scenario: Recovery требует нескольких обязательных источников
- WHEN новая сессия восстанавливает разрешённую фазу, для которой нужны native contextFiles, risk inputs и согласованный Design package
- THEN она получает весь применимый набор и именно согласованную версию Design, даже если краткий handoff перечисляет лишь часть источников или документов больше, чем агент первоначально ожидал прочитать
Scenario: Обязательный материал недоступен
- WHEN необходимый для текущего решения input отсутствует либо согласованную версию Design package нельзя однозначно восстановить
- THEN workflow сообщает конкретный blocker и не принимает зависимое решение до восстановления input либо разрешения вопроса на нужной planning boundary
ADDED Requirements
Requirement: Frontend-local conventions имеют единый вход по содержанию изменения
Участник workflow SHALL получать один актуальный набор frontend-local conventions через компактный router, выбирающий документы по содержанию изменения. Router SHALL направлять создание или перенос module/slice и cross-slice imports к правилам структуры; declarations, props, exports, продуктовые строки и сообщения валидации — к conventions; разделение container/VM/view, формы, query states, skeleton и retry/recovery — к правилам UI; HTTP client, generated types, query/mutation, Bearer и refresh — к правилам API; изменение самих тестов или поведения с testing risk trigger — к правилам тестирования. При сочетании triggers участник MUST получать все применимые документы, а не выбирать один взаимоисключающий маршрут.
Router MUST ссылаться на применимые общие authorities вместо пересказа их содержания. Несвязанная задача MUST NOT требовать чтения всех conventions. Перенос SHALL сохранять полезное содержание всех шести существующих документов, обязательные требования и действующие исключения, не оставляя двух поддерживаемых копий. Общая engineering policy, architecture, ADR и as-built documentation MUST сохранять своих существующих владельцев.
Все применимые действующие ссылки SHALL разрешаться к актуальным владельцам после переноса, включая ссылки из optional entrypoints, если они затронуты. Historical archives, dated audit snapshots и прежнее Completion Evidence MUST оставаться неизменными; их старые пути MUST NOT считаться действующей навигацией, требующей переписывания.
Scenario: UI-only изменение не затрагивает данные и testing risk
- WHEN задача меняет только представление и props существующего компонента без изменения структуры модулей, взаимодействия с сервером, тестов или поведения с testing risk trigger
- THEN router направляет к UI rules и component conventions; правила API, структуры и тестирования не становятся обязательными только из-за того, что изменён frontend
Scenario: Меняются ownership авторизации или refresh
- WHEN задача затрагивает формирование авторизации запросов либо координацию refresh
- THEN router включает правила API и тестирования по security/concurrency risk, а применимый contract и domain context остаётся обязательным независимо от того, меняется ли интерфейс
Scenario: Меняются сами тесты
- WHEN задача изменяет тесты без изменения production behavior
- THEN router включает testing conventions; отсутствие изменения production behavior не отменяет этот trigger, а остальные документы выбираются по фактически затронутым границам
Scenario: Создаётся slice с импортом другого slice
- WHEN задача создаёт или переносит slice либо меняет cross-slice import
- THEN router включает structural conventions и public API boundaries до решения о размещении или импорте, даже если внешнее поведение сохраняется
Scenario: Меняются только продуктовые строки или сообщения валидации
- WHEN задача меняет продуктовый текст либо пользовательские сообщения валидации без изменения структуры, UI-state logic, API и тестов
- THEN router включает conventions локализации и валидации, не требуя остальных локальных документов при отсутствии их triggers
Scenario: Задача не относится к frontend conventions
- WHEN задача исправляет опечатку в общей документации, не меняет frontend-local instructions и не затрагивает frontend behavior или boundaries
- THEN workflow использует применимые общие и docs-local authorities без обязательного чтения frontend conventions
Scenario: Участник открывает действующую ссылку после переноса
- WHEN участник переходит к frontend-local conventions из действующей навигации после их переноса
- THEN ссылка ведёт к единственному актуальному владельцу, где сохранены применимые требования и исключения; прежнее расположение не содержит второй поддерживаемой копии правил
Scenario: Старый путь встречается в historical artifact
- WHEN прежний путь к conventions встречается в historical archive, dated audit snapshot или старом Completion Evidence
- THEN artifact и его историческая ссылка сохраняются без переписывания; актуальный маршрут определяется действующими entrypoints
Requirement: Активные инструкции точно описывают обязательность и способ обеспечения правил
Активные instructions SHALL различать автоматическое блокирование существующим gate, обязательную процедуру или semantic review и необязательное guidance. Инструкция MUST NOT обещать автоматическую проверку, которой нет в текущей конфигурации. Отсутствие автоматической проверки MUST NOT превращать обязательное требование локализации, валидации или другой действующий invariant в пожелание. Успех structural checks MUST NOT объявляться semantic approval или независимым Validation PASS.
Testing guidance SHALL соответствовать объявленным зависимостям и используемой тестовой инфраструктуре; наличие пакета только как транзитивной зависимости MUST NOT представляться как его прямое принятие проектом. Исправление guidance в рамках этого этапа MUST NOT требовать нового dependency package или менять runtime behavior.
Заменённые части действующего ADR SHALL иметь явную историческую квалификацию и направление к текущей принятой процедуре с сохранением rationale и правил ведения ADR. Документация MUST опираться на фактическое состояние, а не повторять неподтверждённое утверждение об удалении или наличии инструмента. Числовые детали UI-каталога SHALL принадлежать его документу-владельцу; workflow summaries SHALL ссылаться на него. Использование уже поставленного каталога MUST NOT трактоваться как новое добавление, требующее повторного approval установки.
Scenario: Автоматическая проверка не блокирует непереведённую строку
- WHEN текущие style и type checks допускают произвольную непереведённую продуктовую строку
- THEN инструкции сохраняют обязательную локализацию и semantic review, не обещают автоматический запрет такой строки и не считают успешный gate доказательством выполнения этого требования
Scenario: Нарушение действительно блокируется существующим gate
- WHEN текущее tooling детерминированно отклоняет нарушение документированного component style в применимом scope
- THEN инструкция описывает это правило как автоматически проверяемое с сохранением действующих исключений, не переводя его в guidance
Scenario: Рекомендованный testing helper не объявлен напрямую
- WHEN прежнее guidance рекомендует helper из пакета, не объявленного прямой dependency, а действующие тесты используют доступные средства
- THEN guidance согласуется с принятой инфраструктурой без добавления пакета ради прежнего текста; транзитивная доступность описывается точно
Scenario: Часть ADR описывает заменённую процедуру
- WHEN описание схемы или orchestration в ADR отличается от текущей принятой процедуры
- THEN участник может отличить историческую часть решения от действующей процедуры и перейти к её authority; rationale и исторические artifacts сохраняются, а неподтверждённое удаление инструмента не утверждается
Scenario: Workflow ссылается на существующий UI-каталог
- WHEN участник использует уже поставленный каталог как reference
- THEN он получает актуальные числовые детали у документа-владельца без второй копии в workflow и без повторного approval добавления каталога; требования к отдельному approval Design package и независимой Validation продолжают действовать