Шаблоны документов BR / SR / TR / TC / AR / ACTZ / AT¶
Статус: informative. Это возможная реализация нормативных схем — организации могут дорабатывать заготовки под свой носитель и редакционные конвенции. Нормативный текст, который шаблоны лишь иллюстрируют:
standard/06(BR / SR / TR),standard/07 §7.4.6(AR),standard/07 §7.13(ACTZ) иstandard/09(TC, AT). При расхождении заготовки и главы стандарта главенствует глава.Закрытый список не затрагивается: приложение даёт заготовки для уже нормированных типов; новые типы артефактов или SPEC добавляются только через формальную процедуру изменения стандарта (глава 13). AR — запись-свидетельство, а не тип требования, и ни в один закрытый список не входит (§1.7.5).
12.1 Статус и как пользоваться¶
Каждый раздел ниже содержит две заготовки: блок yaml с frontmatter (с построчными комментариями об обязательности полей) и блок markdown со скелетом тела. Чтобы получить готовый файл артефакта, склейте обе части в один документ носителя: frontmatter сверху, тело — следом.
Соответствие заготовок нормативным схемам:
| Артефакт | frontmatter (норма) | Разделы тела (норма) |
|---|---|---|
| BR | §6.5.2 | §6.5.3 |
| SR | §6.6.2 | §6.6.3 |
| TR | §6.7.2 | §6.7.3 |
| TC | §9.3 | §9.4 |
| AR | §7.4.6.2 | §7.4.6.2 |
| ACTZ | §7.13.3 | §7.13.3, §7.13.5 |
| AT | §9.19.3 | §9.19.3 |
Условные обозначения в заготовках: <...> — плейсхолдер для замены; NN — порядковый номер в рамках scope; комментарий # conditional помечает поле, обязательность которого зависит от условия (поясняется тут же); # auto — поле, которое ведёт носитель/runner, автор его не заполняет вручную.
12.2 Шаблон BR¶
BR фиксирует бизнес-потребность на уровне системы или подсистемы; технические детали в BR запрещены (§6.5.1). Frontmatter — по §6.5.2; тело — по §6.5.3.
---
id: BR-NN # неизменяемый; NN — порядковый в рамках scope
title: "<краткое описательное название>"
type: BR
slug: "<kebab-case>" # выводится автоматически
# === Scope (обязательно) ===
level: system | subsystem # BR на уровне модуля запрещён (§6.4)
scope:
system: "<system-id>"
subsystem: "<subsystem-id>" # null, если level=system
# === Жизненный цикл (обязательно) ===
status: draft | approved | verified | deprecated
owner: "<роль / ответственное лицо>"
# === Источник: происхождение (см. §7.4.1) ===
source:
tz-section: "§N.N" # обязательно всегда — первичное происхождение из TZ
adapt: ADAPT-NNN # conditional: присутствует, если ADAPT создавался
adapt-section: "Forward §N" # обязательно, если задано adapt
adversarial-review-ref: AR-NNN # conditional: при отсутствии adapt — AR с вердиктом «нет находок» (§7.4.1.2)
# === Межуровневая связь BR подсистемы → BR системы (см. §6.8.2) ===
implements: # массив; не parent-edge, отдельный тип ребра
- id: BR-NN # ID BR родительской системы
scope:
system: "<system-id>"
rationale: "<кратко>" # опционально; ссылка на раздел ADAPT при наличии
# === Граф связей (ведётся носителем) ===
children: [] # auto: SR со ссылкой parent.id = этот BR
implemented-by: [] # auto: BR подсистем, ссылающиеся через implements[]
verified-by: [] # auto: TC, верифицирующие через SR
# === Происхождение от ИИ (обязательно на RENAR-4+; схема — §4.10.1) ===
ai-provenance:
generated-by: "<vendor>-<model>@<дата>"
generated-at: "<ISO-8601>"
human-edits: boolean
# === Замена (обязательно, если применимо) ===
replaces: "<old-id>"
replaced-by: "<new-id>"
deprecated-date: "<ISO-дата>"
---
## Потребность
Кто (роль), что (действие), зачем (бизнес-цель) — одно предложение.
## Критерии успеха
1. <Измеримый результат, поддающийся независимой проверке.>
2. <…> (всего 3–7 пунктов.)
## Контекст
Откуда взялось требование (со ссылкой на раздел ADAPT при наличии); какие
альтернативы рассматривались.
## Ограничения
<Опционально: бизнес-ограничения — бюджет, сроки, регуляторика. Технические
ограничения здесь не место — для них существуют типы SPEC и SR.>
Поле source.tz-section присутствует всегда; source.adapt опускается, когда состязательный обзор вынес вердикт «нет находок» — тогда обязателен source.adversarial-review-ref (§7.4.1).
Где в BR «требования». В шаблоне BR намеренно нет раздела с формулировками вида «система должна …»: в RENAR такие формулировки — это SR (§6.6), производные от данного BR. Смешение их с BR размывает границу «бизнес-потребность ↔ требование к системе» и порождает «технические BR», неотличимые от SR (§6.4, §6.5.1). Проверяемое, перечислимое содержание самого BR несёт раздел «Критерии успеха»: 3–7 измеримых, независимо проверяемых результатов — это и есть бизнес-требования в проверяемой форме. Декомпозиция BR → SR превращает каждый критерий в одно или несколько нормативных SR (форма «система должна …» по §6.6.3).
12.3 Шаблон SR¶
SR фиксирует, что делает система (наблюдаемое поведение и ограничения); имена таблиц, фреймворков и структур данных — ответственность SPEC (§6.6.1). Frontmatter — по §6.6.2; тело — по §6.6.3.
---
id: SR-NN # неизменяемый
title: "<краткое описательное название>"
type: SR
slug: "<kebab-case>"
# === Scope (обязательно) ===
level: system | subsystem | module
scope:
system: "<system-id>"
subsystem: "<subsystem-id>" # null, если level=system
module: "<module-id>" # null, если level ≠ module
# === Жизненный цикл (обязательно) ===
status: draft | approved | verified | deprecated
owner: "<роль / ответственное лицо>"
# === Родитель (обязательно) ===
parent:
id: BR-NN # единственный родитель
# === Источник: происхождение (см. §7.4.1; правила те же, что у BR) ===
source:
tz-section: "§N.N" # обязательно всегда
adapt: ADAPT-NNN # conditional
adapt-section: "Forward §N" # обязательно, если задано adapt
adversarial-review-ref: AR-NNN # обязательно, если adapt опущено — AR (§7.4.6)
# === Характеристика качества (conditional; §6.6.2) ===
# обязательно для нефункционального SR; значение — из перечня ISO/IEC 25010:2023.
# Для функционального SR поле опускается.
quality-characteristic: functional-suitability | performance-efficiency | compatibility |
interaction-capability | reliability | security | maintainability |
flexibility | safety
# === Граф связей ===
constrained-by: # типизированные рёбра к SPEC (глава 8)
- SPEC-UI-NN
- SPEC-API-NN
- SPEC-DATA-NN
children: [] # auto: TR со ссылкой parent.id = этот SR
verified-by: [] # auto: TC, верифицирующие SR
# === Происхождение от ИИ (обязательно на RENAR-4+) ===
ai-provenance:
generated-by: "<vendor>-<model>@<дата>"
human-edits: boolean
# === Замена (обязательно, если применимо) ===
replaces: "<old-id>"
replaced-by: "<new-id>"
deprecated-date: "<ISO-дата>"
---
## Требование
Одно предложение нормативной формы: «Система должна …» (модальность — по
конвенции §0.5).
## Поведение
Детальное описание наблюдаемого поведения; функциональные сценарии.
## Ограничения
<Обязательно, если применимо: нефункциональные ограничения — производительность,
безопасность. Полные ограничения выносятся в SPEC через constrained-by[].>
## Связь с SPEC
<Обязательно при наличии constrained-by[]: какие аспекты поведения нормированы
какими SPEC.>
parent.id — единственный BR (дерево родителей); constrained-by[] — граф ссылок на SPEC любого типа и в любом числе (§6.6.2).
12.4 Шаблон TR¶
TR — атомарная единица работы исполнителя: что именно реализовать в рамках одного SR (§6.7.1). Frontmatter — по §6.7.2; тело — по §6.7.3.
---
id: TR-NN # неизменяемый
title: "<краткое описательное название>"
type: TR
slug: "<kebab-case>"
# === Scope (обязательно) ===
level: system | subsystem | module # system — редко, кросс-подсистемные задачи
scope:
system: "<system-id>"
subsystem: "<subsystem-id>" # null, если level=system
module: "<module-id>" # null, если level ≠ module
# === Жизненный цикл (обязательно) ===
status: draft | approved | done | obsolete
owner: "<роль исполнителя / агент>"
# === Родитель (обязательно) ===
parent:
id: SR-NN # единственный родитель
# === Источник: цепочка прослеживаемости (наследуется от parent SR, §6.7.5) ===
source:
adapt: ADAPT-NNN # auto: наследуется от parent SR; может отсутствовать
sr-version: "<version-ref>" # фиксация к версии SR (возможность носителя V5)
# === Граф связей ===
implements-spec: # типизированные рёбра к SPEC
- SPEC-API-NN
- SPEC-UI-NN
verified-by: [] # auto: TC, верифицирующие через SR
# === Цель и критерии приёмки ===
goal: "<результат в одном предложении>"
acceptance-criteria:
- "<нумеруемое, опровержимое, без двусмысленности>"
- "<…>"
# === Происхождение от ИИ (обязательно на RENAR-4+) ===
ai-provenance:
generated-by: "<vendor>-<model>@<дата>"
human-edits: boolean
---
## Goal
Один параграф; результат, который TR делает наблюдаемым.
## Acceptance Criteria
1. <Опровержимый критерий; покрывает положительный сценарий.>
2. <Опровержимый критерий; покрывает отрицательный сценарий / границу.>
## Scope
Что входит и что **не** входит в TR (соответствует SENAR Rule 2).
## Ссылки
<Обязательно, если применимо: на SPEC из implements-spec[] и разделы
родительского SR.>
Имена секций Goal, Acceptance Criteria, Scope — канонические по §6.7.3. Исполнитель TR работает в рамках SR / SPEC и к ADAPT напрямую не обращается (§6.7.5).
12.5 Шаблон TC¶
TC верифицирует нормативное утверждение BR / SR / SPEC; общий frontmatter — по §9.3, тело — по §9.4. Type-specific поля (judge, baseline для ux / eval) добавляются поверх по §9.6.
---
# === Идентичность (обязательно) ===
id: TC-NN # неизменяемый; NN — порядковый в рамках scope
title: "<краткое описательное название>"
type: TC
slug: "<kebab-case>"
# === Классификация (обязательно) ===
tc-type: business | ux | system | contract | eval | security # business — каноническое имя (§9.5)
negative: boolean # true для парного негативного TC
# === Scope (обязательно) ===
level: system | subsystem | module
scope:
system: "<system-id>"
subsystem: "<subsystem-id>" # null, если level=system
module: "<module-id>" # null, если level ≠ module
# === Жизненный цикл (обязательно) ===
status: draft | ready | passing | failing | obsolete
# === Цель верификации (обязательно; хотя бы одна) ===
verifies:
- id: SR-NN | BR-NN | SPEC-<TYPE>-NN
requirement-version: "<version-ref>" # фиксация версии артефакта (V5)
# === Парная связь (обязательно, если negative=false и парный существует) ===
paired-with:
- TC-NN
# === Привязка к задаче (опционально; §9.19.7) ===
verifies-tr: TR-NN # задача, к объёму которой сужен тест
verifies-claims: [] # подмножество утверждений родительского SR в объёме этой TR
# === Стенд и данные (conditional; §9.3) ===
environment-ref: SPEC-TEST-NN # обязательно, если automation.kind: dynamic — стенд и датасет,
# против которых TC валиден. Для static (док-линт, структурный TC)
# не применяется: анализатор работает по артефактам
# === Автоматизация (обязательно) ===
automation:
status: automated | manual-pending
kind: dynamic | static # обязательно; static — runner является статическим анализатором
location: "<ссылка-носителя на реализацию>" # обязательно, если automated
manual-pending-until: "<ISO-дата>" # обязательно, если manual-pending
manual-pending-reason: "<текст>" # обязательно, если manual-pending
# === Красная история (§9.18.2; условие засчёта TC как доказательства) ===
red-history: # auto: ведёт носитель по фактам прогонов
fixing-run: # фиксирующий прогон до реализации; обязан быть красным
date: "<ISO-datetime>"
result: fail
green-transition: # записанный переход красный → зелёный
date: "<ISO-datetime>"
inherited-from: null # conditional: TC-NN, если поведение не менялось (рефакторинг, миграция)
not-applicable-reason: null # conditional: implementation-originated — тогда обязателен убитый мутант
mutation-check: # обязательно, если задано not-applicable-reason
mutants-killed: 0 # ≥ 1, иначе TC не является доказательством
# === Прогон (обязательно для tc-type: ux | eval) ===
judge:
vendor: "<provider>" # обязательно; изоляция судьи — P7
model: "<model-id>"
baseline: # обязательно для ux | eval
artifact: "<ссылка-носителя>"
perceptual-diff-threshold: float # для ux
metric-thresholds: {} # для eval
# === Последний прогон (ведёт runner; автор не заполняет) ===
last-run: # auto
date: "<ISO-datetime>"
result: pass | fail | skipped | n/a
runner-id: "<runner-name@version>"
# === Происхождение от ИИ (обязательно на RENAR-4+) ===
ai-provenance:
generated-by: "<vendor>-<model>@<дата>"
human-edits: boolean
---
## Контекст
На какой пункт верифицируемого артефакта ссылается TC; цитата или пересказ
утверждения.
## Предусловия
Состояние системы и данных, требуемое для прогона; обеспечивается
seed-механизмом.
## Шаги
Действия runner. Для tc-type: ux — намерения, не селекторы (§9.6.1).
## Pass-критерий
Бинарный, наблюдаемый, воспроизводимый (§9.11).
## Fail-критерий
Перечень наблюдаемых признаков нарушения (не отрицание Pass-критерия): утечки,
side-effects, состояния гонки.
## Постусловия
Какое состояние ожидается после прогона; cleanup-механизм.
## Out of scope
Что **намеренно** не проверяется, с указанием парного TC, где это покрыто.
Поле environment-ref обязательно для динамических TC (automation.kind: dynamic): «тест пройден» имеет смысл только против конкретного стенда и конкретных данных (§9.3). Для статических проверок (док-линт, структурный TC) поле не применяется — анализатор работает по артефактам. Ссылка ведёт на SPEC-TEST (§8.5.10); смена стенда или датасета инкрементит его версию и точечно инвалидирует verified у зависимых TC.
Заголовки ## Pass-критерий и ## Fail-критерий фиксированы: их детектирует хук контроля смены критериев (§10.11.3) — локально переименовывать нельзя. Раздел «Out of scope» обязателен: его отсутствие блокирует переход TC в ready (§9.4).
12.6 Шаблон AR — запись состязательного обзора¶
AR фиксирует факт и исход обязательного состязательного обзора (§7.4.6). Это запись-свидетельство, а не артефакт требований: у неё нет родителей, потомков и тест-кейсов. Выпускается в обоих исходах обзора — и когда ADAPT создаётся, и когда нет.
---
id: AR-NNN # неизменяемый; NNN — сквозной в рамках родительского ТЗ
type: AR
tz-ref: TZ-YYYY-NNN # обязательно; обозреваемое (delta-)ТЗ
trigger-stage: import-tz # обязательно: import-tz | decompose-br | decompose-sr | spec | tc
# === Рецензент (обязательно; изоляция §7.10.2) ===
reviewer:
vendor: "<провайдер>"
model: "<идентификатор-модели>" # обязан отличаться от модели основного агента
# === Вердикт (обязательно) ===
verdict: no-findings # no-findings | findings-present
produces-adapt: [] # conditional: непустой при findings-present; пуст при no-findings
# === Жизненный цикл (обязательно) ===
status: issued # draft | issued | superseded
superseded-by: null # conditional: AR-NNN, если status=superseded
# === Подпись (обязательно для issued; возможность носителя V6) ===
signature:
author: "<идентификатор-рецензента>"
timestamp: "<ISO-8601>"
---
Тело при verdict: no-findings:
## Обоснование однозначности
Почему конвертация обозреваемых разделов ТЗ в требования не порождает разрыва: чем закрыт
каждый из рисков (термины, границы работ, умолчания).
## Охват обзора
Разделы ТЗ, вошедшие в обзор, и стадия деривации, на которой он проводился.
Тело при verdict: findings-present:
## Охват обзора
Разделы ТЗ, вошедшие в обзор, и стадия деривации.
## Порождённые находки
Указатели на записи `B-NNN` в порождённом ADAPT — **без дублирования** их содержания:
сами находки живут в ADAPT (§7.4.4).
Выпущенная (issued) AR неизменяема. Если повторный обзор на той же стадии выносит новый вердикт — выпускается новая AR, а прежняя переводится в superseded с заполненным superseded-by. Ссылаться из source.adversarial-review-ref на AR в статусе draft либо superseded запрещено — гейт даёт fatal (§10.11.1).
12.7 Шаблон ACTZ — протокол уточнения ТЗ¶
ACTZ — артефакт контрактного контура: порция вопросов, предложений и решений, вынесенная клиенту и подписанная обеими сторонами (§7.13). Решения формулируются на языке обязательств («кнопка называется X»), а не толкования. Frontmatter — по §7.13.3; приложения к ТЗ — по §7.13.5.
---
id: ACTZ-NNN # неизменяемый; сквозной в рамках родительского ТЗ
title: "Протокол уточнения ТЗ № N"
type: ACTZ
tz-ref: TZ-YYYY-NNN # обязательно; ТЗ, к которому относится протокол
# === Закрываемые находки (conditional) ===
resolves: # записи B-NNN в ADAPT, которые закрывает протокол
- id: B-NNN # отсутствует у протокола по инициативе клиента (§7.13.2)
adapt: ADAPT-NNN
# === Решения (обязательно; непустой список) ===
decisions:
- number: "§M" # стабильный номер пункта; цель ссылки decided-in
statement: "<решение на языке обязательств>"
tz-section: "§N.N" # уточняемый раздел ТЗ
# === Приложения к ТЗ (conditional; §7.13.5) ===
annexes:
- name: "<приложение>"
version: "<новая версия>"
document-ref: "<ссылка-носителя>"
# === Жизненный цикл (обязательно) ===
status: draft # draft | sent | signed | superseded
superseded-by: null # conditional: ACTZ-NNN, если status=superseded
# === Подписи (обязательны для signed; возможность носителя V6) ===
client-signature:
signed-by: "<имя>"
role: "<роль представителя с полномочиями>"
organization: "<организация клиента>"
signed-at: "<ISO-datetime>"
vendor-signature:
signed-by: "<имя>"
role: "<роль>"
signed-at: "<ISO-datetime>"
---
## Предмет уточнения
Какие разделы ТЗ уточняются и почему возник вопрос — со ссылкой на раздел ТЗ (и на
находку `B-NNN` в ADAPT при её наличии).
## Решения
1. **§1.** <Решение на языке обязательств; проверяемая формулировка.>
2. **§2.** <…>
Нумерация пунктов стабильна: на неё ссылаются `B-NNN.decided-in` и `AT.verifies[]`.
## Приложения
<Обязательно, если применимо: перечень новых версий приложений к ТЗ, утверждаемых
этим протоколом (§7.13.5). Прежняя версия остаётся неизменяемой.>
## Подписи
Двусторонняя подпись: клиент (или его представитель с полномочиями) и исполнитель.
Подписанный ACTZ не редактируется: исправление — только новым протоколом, отменяющим прежнее решение (superseded-by). Ссылаться из decided-in на ACTZ в статусе draft запрещено (§7.13.4). Итоговое ТЗ = начальное ТЗ с приложениями плюс все подписанные ACTZ (§7.14).
12.8 Шаблон AT — приёмочный тест контрактного контура¶
AT выводится исключительно из итогового ТЗ и проверяет соответствие контракту, а не интерпретации (§9.19). Создаёт AT изолированный агент: на вход подаётся только итоговое ТЗ, доступ к ADAPT, BR / SR / SPEC, TC и коду запрещён; нарушение изоляции — fatal. Frontmatter и тело — по §9.19.3.
---
id: AT-NN # неизменяемый
title: "<краткое описательное название>"
type: AT
negative: boolean # обязательно; парность pos/neg — как у TC (§9.7)
# === Цель верификации (обязательно; только контрактные ссылки) ===
verifies:
- "TZ §N" # раздел итогового ТЗ
- "ACTZ-NNN §M" # пункт подписанного протокола
# ссылка на BR / SR / SPEC / TC — fatal (§9.19.2)
tz-version: "<редакция итогового ТЗ>" # обязательно; редакция, из которой AT выведен
# === Провенанс изолированного агента (обязательно) ===
generator:
vendor: "<провайдер>"
model: "<идентификатор-модели>" # обязан отличаться от модели основного агента
internal-contour-access: false # обязательно; подтверждение отсутствия доступа к внутреннему контуру
generated-at: "<ISO-8601>"
# === Жизненный цикл (обязательно) ===
status: draft # draft | ready | passing | failing | obsolete
# === Стенд и датасет испытаний (обязательно; §9.19.3) ===
environment-ref: SPEC-TEST-NN # заполняет архитектор или runner ПОСЛЕ генерации:
# изолированный агент внутренних артефактов не видит (§9.19.2)
# === Автоматизация (обязательно) ===
automation:
status: automated | manual-pending
kind: dynamic | static
location: "<ссылка-носителя на реализацию>"
# === Последний прогон (ведёт runner; автор не заполняет) ===
last-run: # auto
date: "<ISO-datetime>"
result: pass | fail | skipped | n/a
runner-id: "<runner-name@version>"
tz-version: "<редакция итогового ТЗ на момент прогона>"
---
## Пункт итогового ТЗ
> «<Дословная цитата проверяемого пункта итогового ТЗ — раздела ТЗ либо пункта
> подписанного ACTZ.>»
Раздел обязателен (`tz_text`, §9.19.3): на приёмке предъявляется сам пункт контракта,
а не пересказ.
## Предусловия
Состояние системы и данных, требуемое для прогона.
## Шаги
Действия runner — сформулированные от лица заказчика, без опоры на внутреннее
устройство системы.
## Pass-критерий
Бинарный, наблюдаемый, воспроизводимый; выводится из процитированного пункта.
## Fail-критерий
Перечень наблюдаемых признаков несоответствия контракту.
## Out of scope
Что **намеренно** не проверяется, с указанием парного AT, где это покрыто.
AT перегенерируются перед каждыми испытаниями от действующей редакции итогового ТЗ: устаревшая программа испытаний к прогону не допускается (§9.19.4). Продукт не предъявляется к сдаче, пока не все AT в статусе passing (§10.4.3).
12.9 SPEC-шаблоны — отложены¶
Заготовки для типов SPEC (глава 8) в это приложение намеренно не включены. Партнёрское ревью отметило вопрос SPEC-заготовок как открытый: набор обязательных полей у SPEC-типов (UI, API, DATA, AI, SEC, INT) различается сильнее, чем у BR / SR / TR / TC, и преждевременная фиксация заготовки рискует прочитаться как нормативная.
Черновые наброски SPEC-заготовок ведутся в репозитории — research/17-specification-schema-and-templates.md (§5; внутренний черновик, на сайт не публикуется) — до отдельного решения. Когда решение будет принято, SPEC-заготовки добавляются сюда новым разделом — без изменения закрытого списка типов SPEC, который уже нормирован в standard/08 §8.2.2 и §8.3.
Закрытый список насчитывает одиннадцать типов: к девяти структурным добавлены SPEC-TEST (стенды и данные — чем доказывается соответствие) и SPEC-DOC (состав поставляемой документации). Отсрочка заготовок распространяется и на них: схемы полей обоих типов даны в reference/02 (разделы 6.3 и 6.4), заготовки документов — нет.
12.10 Заполнение плейсхолдеров и частые ошибки¶
| Плейсхолдер | Чем заменить | Частая ошибка |
|---|---|---|
BR-NN / SR-NN / TR-NN / TC-NN / AT-NN |
Порядковый ID в рамках scope (носитель присваивает при создании) | Менять ID после публикации — он неизменяемый |
ACTZ-NNN / decisions[].number |
Сквозной номер протокола и стабильный номер пункта решения | Перенумеровывать пункты подписанного протокола — на них ссылаются decided-in и AT.verifies[] |
AT.verifies[] |
Только TZ §N и ACTZ-NNN §M |
Сослаться на SR / SPEC / TC — нарушение изоляции, гейт даёт fatal |
<system-id> / <subsystem-id> / <module-id> |
Идентификаторы из реестра систем проекта | Заполнять subsystem, когда level=system (должен быть null) |
source.tz-section |
Раздел исходного ТЗ — присутствует всегда | Опускать его, полагая, что хватит ссылки на ADAPT |
constrained-by[] / implements-spec[] |
ID существующих SPEC | Указывать тип SPEC вне закрытого списка |
Поля # auto (children, verified-by, last-run) |
Ничего — их ведёт носитель / runner | Заполнять вручную и расходиться с графом связей |
Плейсхолдеры вида BR-NN и пустые <...> — это незаполненная заготовка, а не валидный артефакт: пропускайте такие файлы через проверки только после подстановки реальных значений, иначе валидаторы носителя справедливо отклонят шаблонные ID.