Начать или продолжить SDD

Прочитай установленное правило sdd-pipeline. В .AI его источник - .AI/rules/sdd-pipeline.md, в legacy - .claude/rules/sdd-pipeline.md; внутри канона - rules/sdd-pipeline.md. Если правило не установлено, прочитай доступный проектный контекст, найди существующего Markdown-владельца или создай его в проектном бэклоге; запиши blocked, причину и следующий шаг. Сообщи ограничение: не собирай протокол по памяти и не запускай обновление или миграцию автоматически.

В .AI прочитай START, project.md и индекс общей памяти; в legacy - проектные инструкции. Проверь, принят ли SDD и для какой области. Вызов навыка для конкретной задачи разрешает провести эту задачу по SDD, но не включает его для всего проекта без решения владельца.

Найди Markdown-владельца по теме или ID в установленном проектном бэклоге. Продолжай существующего, новый создавай только при отсутствии владельца. При возобновлении прочитай задачу, спеки и отчеты, сверь проверенную ревизию с текущими файлами. Несовпадение требует новых проверок затронутого результата, а не повторного объявления старого успеха.

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

Единица работы - одна задача или ограниченный заранее пакет совместимых задач, только если они помещаются в полноценное общее ревью. Пакет имеет одного Markdown-владельца, общую спеку и матрицу child ID → инвариант → исполнитель → проверка; у каждого child остаются свой owner/ID/status/критерии и независимый значимый RED до реализации. Не объединяй backlog автоматически. Пересечение файлов ведет один писатель либо участники работают последовательно; разные файлы с общими API/state/schema связываются проверками матрицы. Риск, требующий отдельного доказательства, отката или выпуска, выделяй в отдельный scope.

Пока пакет собирается, запускай нужные локальные проверки. Один независимый reviewer и полный CI покрывают все child и интегрированные эффекты на стабильном точном SHA; если полного покрытия не получается, раздели пакет/ревью и заверши общей integration-сверкой. Любой failing child блокирует пакет; явное разрешенное исключение пересматривает scope, оставляя child открытым в backlog. После правок делай затронутые проверки и актуальную независимую delta-сверку; любое изменение после полного CI требует повторного полного CI. Не переиспользуй stale GREEN. Сохраняй authority и фактическую device acceptance; CI их не заменяет. Общие планирование, интеграцию, ревью и CI записывай один раз у владельца пакета, без сложения inclusive parent total с child receipts.

Модель и текущие назначения

Перед новым заданием и запуском применяй маршрутизацию моделей: свежий MODELS выше канонического дефолта. Границы данных и полномочий этого навыка сохраняются.