Spec-traceability становится автоматическим слоем pipeline
/dr-spec больше нет. Тот же граф-валидатор, который трассировал каждое требование до его доказательства, теперь запускается автоматически внутри /dr-prd, /dr-plan, /dr-do, /dr-qa и /dr-compliance — без отдельного шага, без отдельного вызова.
Datarim 2.58.0 выводит из обращения standalone-команду /dr-spec и продвигает её движок — spec-graph-gate.sh — до автоматического слоя, встроенного в пять стадий pipeline. Если вы использовали /dr-spec раньше, вы ничего не теряете: тот же валидатор теперь работает сам, молча, на каждой стадии, которая производит или потребляет spec-артефакты.
Что делает spec-traceability
В своей основе spec-traceability отвечает на один вопрос: у каждого ли требования есть доказательство? Он строит направленный граф из четырёх артефактов, которые задача уже производит:
wish_id → D-REQ → V-AC → plan-step → evidence
Каждый узел в этой цепочке — конкретный артефакт, который pipeline уже генерирует: acceptance wish в PRD, производное требование (D-REQ-NN), верифицируемый acceptance criterion (V-AC-NN), plan step, который его реализует, и доказательство — тест, измерение, файл — подтверждающее, что шаг сработал. Граф-валидатор проверяет, что каждый wish покрыт, каждый критерий трассирован, и у каждого шага есть evidence. Никакого параллельного дерева спецификации, никакого второго pipeline, никакой внешней зависимости.
Путь: standalone → авто-слой
Spec-traceability появился в v2.42.0 как /dr-spec — standalone-команда проверки только для чтения. Вы вызывали её вручную после стадии, чтобы проверить граф требований. Она работала, но добавляла шаг — а шаги, которые надо помнить, иногда пропускают.
Обратная связь первого месяца использования была однозначной: валидатор достаточно ценен, чтобы запускаться каждый раз, а не только когда кто-то вспомнил его вызвать. В v2.58.0 (<TASK-ID>) /dr-spec выведен из обращения, а его движок — spec-graph-gate.sh — подключён напрямую к стадиям pipeline, которые производят или потребляют spec-артефакты:
/dr-prd— проверяет, что каждый wish имеет трассируемый идентификатор и утверждение о покрытии./dr-plan— проверяет, что каждый acceptance criterion привязан к plan step./dr-do— проверяет, что каждый завершённый шаг несёт evidence (советующий режим во время реализации, поскольку доказательства ещё накапливаются)./dr-qa— проверяет полный граф от начала до конца перед архивом./dr-compliance— проверяет, что ни одно требование не было потеряно при hardening.
Детерминированный слой /dr-verify наследует тот же граф через тот же адаптер — его находки Layer 1 несут provenance check_name: "dr-spec-lint:<rule>", без изменений.
Что изменилось и что нет
Изменилось: поверхность вызова. Вы больше не набираете /dr-spec {TASK-ID}. Проверка графа запускается автоматически при завершении стадии — она часть стадии, а не отдельная команда после неё.
Не изменилось: всё остальное. Четыре pure-shell валидатора над общим реестром правил — те же файлы:
dev-tools/dr-spec-lint.sh— ядро граф-валидатора, именованные правила, поддержка--scope git-diff.dev-tools/dr-trace.sh— группы покрытия: covered / uncovered / dangling / orphaned / deferred.dev-tools/dr-lint.sh— зонтичный фасад с интроспекцией реестра правил и fail-closed защитой обязательных правил.dev-tools/dr-spec-grade.sh— только вычисляемая проекция, никогда не редактируется вручную, никогда не влияет на роутинг.dev-tools/dr-spec-rules.yaml— единый источник истины для набора правил.
Все пять разделяют один контракт: --format json, exit 0/1/2, и неправильно сконфигурированный набор правил — это ошибка конфигурации (exit 2), а не молчаливое «0 нарушений». Стратегия развёртывания advisory-first (dry-run → baseline → advisory window → hard gate) не изменилась.
Почему авто-слой — правильная поверхность
У standalone-команды проверки есть проблема обнаружения: вы должны знать, что она существует, помнить, что её надо запустить, и помнить когда её запустить. Автоматический слой решает все три:
- Обнаружение — если вы запускаете pipeline, вы получаете проверку. Дополнительных знаний не требуется.
- Последовательность — каждая стадия запускает проверку, релевантную её артефактам. Невозможно забыть проверить план, потому что стадия плана проверяет себя сама.
- Корректность — проверка запускается в правильный момент, против правильных артефактов, с правильным scope. Ручная команда, запущенная слишком рано или слишком поздно, могла пропустить или ложно сработать на незавершённых изменениях.
Стоимость — ноль: граф-валидатор написан на чистом shell, отрабатывает менее чем за секунду на типичной задаче, а его находки используют ту же таксономию severity и роутинг, что и все остальные проверки pipeline. Если вы уже запускали /dr-spec вручную, единственная разница — теперь вам этого делать не нужно.
Количество команд: 27
С выводом /dr-spec из обращения Datarim поставляет 27 команд: 25 pipeline- и utility-команд /dr-* плюс 2 standalone slash-команды (/factcheck и /humanize). Авто-слой убрал команду с поверхности, но сохранил — и усилил — её функцию. Полную запись смотрите в changelog.