26 июля 2026

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_idD-REQV-ACplan-stepevidence

Каждый узел в этой цепочке — конкретный артефакт, который 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.