Глоссарий RENAR¶

Назначение: единый источник канонических терминов RENAR с примерами и mapping на отраслевые стандарты. При расхождении формулировок нормативно побеждает standard/04-terms.md; этот глоссарий — informative lookup для читателя и assessor-а.

1. Цепочка авторитетности¶

В случае разногласий по термину применяется порядок:

standard/04-terms.md — нормативный канон: определения главы стандарта побеждают при любом расхождении.
Этот документ — информационные разъяснения и сопоставление с отраслевыми стандартами; не переопределяет standard/04.
ISO/IEC/IEEE 29148 — международный стандарт инженерии требований.
BABOK Guide v3 — свод знаний по бизнес-анализу (Business Analysis Body of Knowledge).
Изменение через предложение поправки в полный стандарт RENAR — если все источники молчат.

Закрытые списки: главный индекс шестнадцати закрытых списков — standard/01 §1.7.5.

Не используются как источник терминов: тикеты в багтрекере, чаты команды (slang), устаревшие презентации, маркетинговые материалы.

2. Канонические термины¶

2.1 Уровни требований¶

Каноника v1.0 — закрытый список (см. standard/04-terms.md §4.3):

RENAR (канонический)	Полное название	RU (для UI)	Описание
BR	Business Requirement	Бизнес-требование	Бизнес-цель уровня заказчика: что организация хочет получить.
SR	System Requirement	Системное требование	Инженерное требование к ПО; поддаётся проверке. Один `SR` — одна проверяемая единица.
TR	Task Requirement	Требование к задаче	Требование уровня реализации, выводимое из `SR`; единица планирования работ.
TC	Test Case	Контрольный пример (TC)	Проверяемый артефакт, подтверждающий `SR`/`BR`. Описывает поведение, а не реализацию.

Правило идентификации: в frontmatter id — канонический идентификатор RENAR (BR-01, SR-05). При экспорте в другой носитель применяется целевое сопоставление.

Уточнения для SR (по полям frontmatter, не отдельные типы артефактов):

Module SR — SR с level: module (standard/06 §6.7). Раньше отдельный label TM (§2.1.1).
Integration SR — SR с constrained-by: [SPEC-INT-N]. Раньше отдельный label INT-SR (§2.1.1).
Contract TC — TC с tc-type: contract. Раньше отдельный label INT-TC (§2.1.1).

Семейство SPEC (UX / ИИ / архитектура / интеграционные спецификации) — см. §14.5 Семейство SPEC.

2.1.1 Legacy labels (deprecated)¶

При миграции с материалов до v1.0 draft встречаются устаревшие метки. Их замены в канонике v1.0 (standard/04-terms.md §4.14.1):

Устаревший label	Замена в канонике v1.0	Пояснение
`TM` (Module/Submodule SR)	`SR` с `level: module`	Уточнение `SR`, не отдельный тип артефакта
`UIC` (UI Concept)	`SPEC-UI` (`standard/08 §8.5.6`)	Часть семейства `SPEC` (§14.5)
`AIC` (AI Concept)	`SPEC-AI` (`standard/08 §8.5.7`)	Часть семейства `SPEC`
`INT-SR` (Integration SR)	`SR` с `constrained-by: [SPEC-INT-N]`	Подкласс `SR`
`INT-TC` (Integration TC)	`TC` с `tc-type: contract`	Подкласс `TC`
`TS` (Technical Specification)	`SPEC-ARCH` или `SPEC-OPS` в зависимости от содержания	Часть семейства `SPEC`

Миграция существующих артефактов: встроенная в носитель привязка к набору изменений должна автоматически распознавать устаревшие метки и предлагать канонические замены. Каноническая таблица сопоставления legacy → v1.0 — standard/04-terms.md §4.14.1.

2.2 ADAPT artifact family¶

Термин	Описание
ADAPT	Адаптивный документ, формулирующий проектное ТЗ (Adaptive Document for Articulating Project's TZ). Двусторонняя инженерная адаптация ТЗ: прямое направление (интерпретация) и обратное (вопросы). Утверждается двойной подписью.
delta-ADAPT	`ADAPT` для delta-ТЗ. Цепочка: ADAPT-001 → ADAPT-001-delta-1 → ADAPT-001-delta-2; применяются по порядку.
errata-ADAPT	Правка утверждённого `ADAPT` (наша ошибка интерпретации). Не меняет замороженный документ — добавляется отдельный артефакт.
Forward (в ADAPT)	Инженерная интерпретация каждого раздела ТЗ: цитата → интерпретация → достроенные сценарии → охват.
Backward (в ADAPT)	Список проблем и вопросов к клиенту. Жизненный цикл: `open` → `asked-to-client` → `answered` → `resolved` → `frozen`.
Term mapping (в ADAPT)	Таблица «термин клиента → инженерное понимание».

2.3 Backward categories (закрытый список)¶

ADAPT backward записи относятся к одной из 7 категорий. Список закрыт; новые добавляются только через изменение полного RENAR Standard:

Категория	Описание
`contradiction`	Противоречие внутри ТЗ.
`gap`	Гэп — про это ТЗ молчит.
`hidden-assumption`	Скрытое предположение инженера, требующее подтверждения.
`feasibility`	Технически нереализуемое или дорогое требование.
`regulatory`	Затрагивает законодательство / compliance.
`terminology`	Неясный или конфликтующий термин клиента.
`scope`	Уточнение границ scope (входит / не входит).

2.4 Контрольные точки качества (`Quality Gates`, закрытый список, каноника v1.0)¶

Закрытый список контрольных точек RENAR (по standard/10-lifecycle-qg.md §10.3–10.4):

Gate	Применяется к	Условие пропуска
QG-0 Контрольная точка утверждения (`Approval Gate`)	Перевод `BR`/`SR`/`SPEC`: `draft` → `approved`	Цель, критерии приёмки, не менее одного негативного сценария и охват; для `SR` — родительский `BR` в `approved`+; для `SR` с `constrained-by` — `SPEC` в `approved`+.
QG-1 Контрольная точка реализации (`Implementation Gate`)	Перевод `TC`: `draft` → `ready` (только для `TC`)	У `TC` поле `verifies` ссылается на артефакт в `approved`+; `requirement-version` совпадает; охват реализации и закрепление версии зафиксированы.
QG-2 Контрольная точка проверки (`Verification Gate`)	Перевод `SR`/`BR`: `approved` → `verified`	Все `TC` из `verified-by` зелёные; хотя бы один `TC` с `negative: true`; у `last-run` совпадает `requirement-version` с текущей `version`; выборочная проверка пройдена.
QG-3 Контрольная точка архитектуры (`Architecture Gate`, опционально)	Утверждение `SPEC-ARCH` / двойная подпись	Зафиксирован артефакт в духе ADR в носителе; двойная подпись (клиент + архитектор). Не обязательна для декларируемого соответствия RENAR.
QG-4 Контрольная точка приёмки (`Acceptance Gate`, опционально)	Перевод `BR`: `verified` → `accepted`	Все `BR` покрыты проверенными `SR`; приёмочные `TC` (`tc-type: acceptance`) зелёные; подпись клиента. Не обязательна для декларируемого соответствия RENAR.

Соответствие стандарту RENAR (соответствие): QG-0 / QG-1 / QG-2 обязательны для декларируемого соответствия (standard/13 §13.3). QG-3 / QG-4 — необязательные расширения.

Список закрыт; новые номера контрольных точек добавляются только через формальную процедуру изменения полного стандарта RENAR.

2.4.1 Устаревшие имена QG (deprecated)¶

До v1.0 в RENAR использовались иные имена контрольных точек. Сопоставление по standard/04-terms.md §4.14.1:

Устаревшее (до v1.0)	Замена в канонике v1.0	Пояснение
`QG-0 Context Gate`	`QG-0 Approval Gate`	Только переименование; смысл сохранён
`QG-1 Requirements Gate`	`QG-1 Implementation Gate`	Сдвиг смысла: ранее утверждение `BR`/`SR`, теперь только перевод `TC`: `draft` → `ready`
`QG-2 Implementation Gate`	`QG-1 Implementation Gate`	Перенумерация и слияние в одну `QG-1`
`QG-3 Verification Gate`	`QG-2 Verification Gate`	Перенумерация
`QG-4 Acceptance Gate`	`QG-4 Acceptance Gate`	Имя то же; теперь опционально для декларируемого соответствия RENAR

Миграция существующих артефактов: средства автоматизации преобразуют ссылки по таблице выше. Каноническая таблица сопоставления legacy QG → v1.0 — standard/04-terms.md §4.14.1.

2.4.2 Локальные контрольные точки ADAPT¶

Жизненный цикл ADAPT (standard/07-adapt.md) использует локальные контрольные точки ADAPT параллельно каноническим QG-N. Это не отдельная нумерация QG, а локальные события жизненного цикла артефакта ADAPT:

Контрольная точка	Применение	Условие прохода
QG-ADAPT-draft	Создание `ADAPT`	Раздел Forward охватывает все разделы ТЗ.
QG-ADAPT-review	Перевод в `review`	Все записи backward — `open` или `asked-to-client`; нет состояния `draft`.
QG-ADAPT-client-ready	Передача клиенту	Все backward — `asked-to-client`; пакет вопросов собран.
QG-ADAPT-answered	После ответа клиента	Все backward — `answered`.
QG-ADAPT-approve	Утверждение `ADAPT`	Все backward — `resolved`; двойная подпись (клиент + архитектор).
QG-ADAPT-frozen	После утверждения	Неизменяемость; разрешена генерация `BR`/`SR`/`SPEC`.

Локальные контрольные точки ADAPT не входят в набор QG-0/QG-1/QG-2 для декларируемого соответствия RENAR. Реализация может выразить QG-ADAPT-approve как локальный псевдоним для QG-3 (Architecture Gate, если применимо) либо хранить отдельно — на усмотрение носителя.

2.5 Семейство SPEC (закрытый список)¶

Тип	Назначение	Источник
SPEC-ARCH	Архитектура системы / подсистемы: контексты, контейнеры, компоненты, представление развёртывания, атрибуты качества	Раздел Forward `ADAPT`
SPEC-API	Контракты API (REST / GraphQL / gRPC / асинхронные события); версионирование, модель ошибок, ограничения частоты	Раздел Forward `ADAPT`
SPEC-DATA	Модель данных: схема, ER-диаграмма, индексы, миграции, хранение, классификация персональных данных	Раздел Forward `ADAPT`
SPEC-INT	Интеграция: взаимодействие между подсистемами и внешними системами; протоколы, контракты, SLA	Раздел Forward `ADAPT`
SPEC-PROC	Процесс / рабочий поток: бизнес-процессы, машины состояний, паттерны saga, оркестровка и хореография	Раздел Forward `ADAPT`
SPEC-UI	UI / UX: экраны, навигация, пользовательские сценарии, доступность, локализация, эталонные изображения	Раздел Forward `ADAPT`
SPEC-AI	ИИ / ML: карточки моделей, RAG, инженерия промптов, стратегия оценки, бюджет стоимости	Раздел Forward `ADAPT`
SPEC-SEC	Безопасность: аутентификация / авторизация, модель угроз, управление секретами, классификация данных	Раздел Forward `ADAPT`, регуляторные замечания backward
SPEC-OPS	Эксплуатация: развёртывание, наблюдаемость, SLO / SLA, runbook, аварийное восстановление	Раздел Forward `ADAPT`

Список закрыт — ровно девять типов (каноника по standard/08 §8.3); новые типы SPEC добавляются только через изменение полного стандарта RENAR.

2.6 Статусы жизненного цикла¶

Статус	Применим к	Значение
`draft`	все артефакты	В работе, не для использования другими
`review`	все	На ревью, возможны изменения
`approved`	ADAPT, SR, SPEC	Утверждён; неизменяем после двойной подписи (для `ADAPT`) или одной (для `SR`/`SPEC`)
`verified`	SR	Подтверждён успешными `TC` и выборочной проверкой
`frozen`	ADAPT	Утверждён и неизменяем; используется как источник для генерации `BR`/`SR`/`SPEC`
`deprecated`	все	Устарел, не используется в новых артефактах; замена (если есть) указывается полем `replaced-by`
`obsolete`	research/legacy	Полностью изъят из обращения

2.7 Возможности носителя (V1–V6)¶

RENAR не привязан к конкретному носителю артефактов. Артефакт может находиться в любом носителе, который удовлетворяет следующим возможностям:

Нормативное определение — standard/03 §3.3:

Возможность	Описание
V1 — неизменяемая история	Любое прошлое состояние артефакта можно адресно восстановить без потерь (цепочка ревизий для аудита сохраняется).
V2 — атомарная единица изменения	Изменение артефакта (или согласованной группы) фиксируется одной транзакцией: целиком успех или целиком откат; промежуточные состояния извне не видны.
V3 — сравнение и ревью (diff)	Предлагаемое изменение можно представить как разницу к базовой версии и принять или отклонить до попадания в утверждённое состояние (основа утверждения и контрольных точек `QG`).
V4 — ветвление и набор изменений	Незавершённая работа отделена от утверждённого источника истины; несколько независимых изменений ведутся параллельно без влияния на источник истины.
V5 — межсценарная фиксация версии	Можно зафиксировать конкретную версию артефакта из другого носителя как разрешимый идентификатор (основа поля `verifies[].requirement-version`).
V6 — автор и метка времени	Для каждой атомарной правки зарегистрированы однозначный автор и метка времени (основа подписи `ADAPT` и блока `ai-provenance`).

Примеры сред: распределённая VCS (git с ревью запросов на слияние), документоориентированное хранилище с цепочкой ревизий и подписями, любая СУБД с историей изменений и подписями. RENAR не требует git — только возможности V1–V6.

2.8 Происхождение ИИ (`ai-provenance`, канонические поля)¶

Во frontmatter любого артефакта, сгенерированного ИИ:

Поле	Тип	Описание
`ai-provenance.generated-by`	string	Модель в формате `<vendor>-<model>-<version>@<date>`. Пример: `anthropic-claude-opus-4-7@2026-05-15`.
`ai-provenance.prompt-template`	string	Путь к шаблону промпта и версия. Пример: `prompts/adapt-from-tz.md@v2.1`.
`ai-provenance.context-tokens`	integer	Число токенов во входном контексте.
`ai-provenance.output-tokens`	integer	Число токенов в выводе модели.
`ai-provenance.generation-time-ms`	integer	Время генерации в миллисекундах.
`ai-provenance.human-edits`	boolean	Значение «истина», если текст после генерации правил человек. Для утверждённых артефактов обязательно `true`.

2.9 Типы контрольных примеров¶

Закрытый список — шесть типов (каноника по standard/09 §9.5):

Тип TC (`tc-type` поле)	ISTQB соответствие	Применение
`acceptance`	Acceptance Testing	Проверка BR (приёмочный).
`ux`	расширение по удобству	Проверка `SPEC-UI` через модель-судью VLM / визуальное сравнение с эталоном (`baseline`).
`system`	System Testing	Проверка SR, SPEC-PROC, SPEC-ARCH.
`contract`	Component Integration Testing	Проверка SPEC-API / SPEC-INT / SPEC-DATA через contract testing (Pact и аналоги).
`eval`	специфично для ИИ	Проверка `SPEC-AI` через оценивающую LLM и метрики (BLEU, точность, доля галлюцинаций).
`security`	расширение по безопасности	Проверка `SPEC-SEC`: инварианты безопасности (STRIDE); нормативно только негативные сценарии (`standard/09 §9.6.4`).

2.10 Связи (frontmatter поля)¶

Поле	Назначение
`parent`	Родитель в иерархии (BR → SR → TR); один источник.
`children`	Дочерние артефакты (выводятся автоматически).
`source.adapt`	`ADAPT`, из которого выведен артефакт (каноника для `BR`/`SR`/`SPEC`).
`source.adapt-section`	Раздел `ADAPT` (Forward §N).
`source.tz-section`	Раздел ТЗ (справочно, для трассируемости).
`verifies` (в `TC`)	`SR`/`BR`, которые покрывает `TC`, с указанием `requirement-version`.
`verified-by` (в `SR`)	`TC`, подтверждающие `SR` (выводятся автоматически).
`derived-from`	Шаблон и версия (если артефакт создан из шаблона).
`replaces` / `replaced-by`	Замена при статусе `deprecated`.
`supersedes` (в новом)	Какое требование заменяется.
`linked-tasks`	Задачи, реализующие `SR` (через среду выполнения, не через файлы).

2.11 Соглашение об именах файлов (по умолчанию)¶

Тип	Шаблон	Пример
ADAPT	`adapt/ADAPT-NNN[-delta-N].md`	`adapt/ADAPT-001-main.md`, `adapt/ADAPT-001-delta-1.md`
BR	`br/BR-NN-<slug>.md`	`br/BR-01-notification-capture.md`
SR	`sr/SR-NN-<slug>.md`	`sr/SR-05-notification-feed.md`
SR подсистемы	`sr/<MODULE>-SR-NN.N-<slug>.md`	`sr/WMS-SR-01.2-pick.md`
SPEC-UI	`specs/ui/SPEC-UI-NN-<slug>.md`	`specs/ui/SPEC-UI-02-notification-feed.md`
SPEC-AI	`specs/ai/SPEC-AI-NN-<slug>.md`	`specs/ai/SPEC-AI-01-rag-strategy.md`
SPEC-INT	`specs/int/SPEC-INT-NN-<slug>.md`	`specs/int/SPEC-INT-01-auth-billing.md`
SPEC (generic)	`specs/<type>/SPEC-<KIND>-NN-<slug>.md`	`specs/api/SPEC-API-03-orders.md`
TC	`tests/TC-NN-<slug>.md`	`tests/TC-01-login-success.md`
ТЗ	`tz/TZ-YYYY-NNN.md`	`tz/TZ-2026-001.md`
Дельта-ТЗ	`tz/TZ-YYYY-NNN-delta-N.md`	`tz/TZ-2026-001-delta-1.md`
UX-эталон	`specs/ui/baselines/SPEC-UI-NN-<scenario>.png`	`specs/ui/baselines/SPEC-UI-02-feed-default.png`
Eval dataset	`specs/ai/eval-datasets/SPEC-AI-NN-<slug>.jsonl`	`specs/ai/eval-datasets/SPEC-AI-01-typical-queries.jsonl`

Соглашение по умолчанию; хранилища, встроенные в конкретную среду, могут использовать иную раскладку при условии устойчивых идентификаторов (возможность V3).

2.12 Маркеры записи об изменении (справочно)¶

В носителе, где атомарные изменения сопровождаются метаданными (текст коммита в git, описание записи об изменении в документоориентированном хранилище), допустимы маркеры:

Маркер	Назначение
`[delta:TZ-YYYY-NNN]`	Изменение по delta-ТЗ.
`[test-spec-change]`	Изменение критериев типа «пройдено / не пройдено» у `TC` (отдельное утверждение).
`[baseline-update]`	Обновление эталона UX или набора для оценки (отдельное утверждение).
`[coverage]`	Автоматическая регенерация сводок по покрытию, плану контрольных примеров и требованиям (бот).
`[reconciliation]`	Изменение от агента согласования (reconciliation).
`[multi-model-disagreement]`	Артефакт с расхождением ответов моделей ИИ — требует ручного ревью.
`[AI]`	Префикс для изменений, сгенерированных ИИ.

Механизм, встроенный в носитель, может выразить эти маркеры полями записи об изменении, метками или тегами — детали не нормируются.

3. Сопоставление со стандартами¶

3.1 Уровни требований¶

Метки каноники v1.0 RENAR и внешние стандарты:

RENAR	ISO/IEC 29148	BABOK	SAFe	Document store (example enum)	SENAR (RU)
BR	Business Requirement	Business Need	Portfolio Epic / Strategic Theme	`BT`	БТ
SR	System / Software Requirement	Solution Requirement (Functional)	Feature	`ST`	СТ
SR (`level: module`)	(область подкомпонента, расширение)	(область подкомпонента)	Story (иногда)	`TM` (legacy)	СТ модуля
SR (`constrained-by: SPEC-INT-N`)	Требование к интерфейсу	Интерфейсное решение	Межфичевая интеграция	(связано)	INT-СТ (legacy)
TR	(нет прямого класса; детализация требования к системе / элементу системы)	Детализированное требование к решению	Story	`TK`	ТЗ
TC	Контрольный пример (Test Case)	Верификация	Приёмочный тест истории	`test_case`	ТК
TC (`tc-type: contract`)	Тест интерфейса	Component Integration Testing	Контрактный тест	(связано)	INT-ТК (legacy)
SPEC-UI	(между BR/SR — проектная спецификация)	Требование стейкхолдера (фрагмент UX)	(уровень проектирования)	(расширение)	UIC (legacy)
SPEC-AI	(расширение REQ)	(н/д)	Enabler	(расширение)	AIC (legacy)
SPEC-ARCH / SPEC-OPS	Описание проектирования	Компонент решения	Enabler tech spec	(расширение)	ТС (legacy)

Примечание: колонки «document store (пример перечисления)» и «SENAR (RU)» содержат исторические метки (TM, UIC, AIC, INT-СТ и т.д.) для трассируемости с системами до v1.0. Колонка каноники RENAR — метки v1.0 согласно §2.1.1. При экспорте в document store или в носитель SENAR применяют целевое сопоставление.

3.2 Контрольные точки качества¶

Сопоставление канонических QG-N v1.0 RENAR с внешними моделями. Устаревшие имена QG (§14.4.1) в колонке SENAR сохранены для исторической трассируемости.

RENAR (v1.0)	SENAR (сопоставление с legacy)	Document store (пример)	Активность CMMI
QG-0 Контрольная точка утверждения	QG-0 (контекст)	`VK-1` (старт)	Проверка требований до обязательств
QG-1 Контрольная точка реализации	QG-2 (реализация в legacy)	`VK-1`	Базовая линия реализации (готовность `TC`)
QG-2 Контрольная точка проверки	QG-3 (верификация в legacy)	`VK-2`	Верификация
QG-3 Контрольная точка архитектуры (опционально)	(н/д)	`VK-3` (частично)	Утверждение архитектурного решения
QG-4 Контрольная точка приёмки (опционально)	QG-4 (Приёмка)	`VK-4`	Приёмка заказчиком

Примечание: до v1.0 QG-1 Requirements Gate фактически разделён между каноническим QG-0 Approval Gate (утверждение BR/SR/SPEC) и QG-1 Implementation Gate (готовность TC). См. §14.4.1 для полного сопоставления.

3.3 Статусы жизненного цикла¶

RENAR	Document store (example)	ISO/IEC 29148	CMMI
`draft`	`draft`	proposed	identified
`approved`	`approved`	agreed-to / baselined	committed
`verified`	`verified`	verified	validated
`deprecated`	`obsolete`	retired	obsolete

3.4 Артефакты процесса¶

RENAR	BABOK	SAFe	SENAR
ADAPT (Forward + Backward)	Requirements Analysis Document	Solution Intent (fixed + variable)	(n/a — RENAR-extension)
Work Order / ТЗ	Stakeholder commitment artifact	Customer order	(контекст)
delta-TZ	Change Request	(n/a — handled via Solution Intent updates)	(контекст)
Impact Analysis	Impact Analysis (BABOK §8)	(derived)	(контекст)
Выборочная проверка	Random sampling QA	(n/a)	Rule 9.5
Состязательный обзор	Independent verification	(n/a — REQ-extension)	(via ADR metric)
Reconciliation	Continuous improvement audit	Inspect & Adapt	Quality Sweep

3.5 Переводы в пользовательском интерфейсе¶

Поля frontmatter, идентификаторы и имена файлов — всегда канонические (латиница). В интерфейсе допустимы русские подписи:

Канонический	UI (RU)
Business Requirement	Бизнес-требование
System Requirement	Системное требование
Test Case	Контрольный пример (`TC`)
Quality Gate	Контрольная точка качества
Acceptance	Приёмка
Verified	Проверено
Approved	Утверждено
Deprecated	Устарело
Frozen	Замороженный
Backward finding	Замечание к ТЗ
Forward interpretation	Инженерная интерпретация

Перевод в интерфейсе не заменяет канонические идентификаторы в носителе.

4. Запрещённые / устаревшие термины¶

RENAR не использует следующие термины (даже если они встречаются в SENAR / отраслевой литературе):

Термин	Что использовать вместо	Почему
User Story как требование	SR	Story — единица планирования, не требование. Story может реализовывать SR, но сама требованием не является.
Use Case (формально)	SPEC-UI + SR	Use case смешивает UX и поведение. RENAR разделяет SPEC-UI (UX-эталон) и SR (поведение).
Spec (без квалификатора)	SR / BR / SPEC-API / SPEC-DATA / ...	«Spec» неоднозначно. Используем точные термины.
Бизнес-логика как требование	SR	«Бизнес-логика» — термин кода, не требований.
Функциональность	`SR` / `TR`	Слишком широко; не поддаётся однозначной проверке.
Фича (mixed-lang)	Feature (SAFe context) или SR (канонический термин RENAR)	Mixed Russian/English; неоднозначно.
Хотелка	(никогда)	Договорный документ так не пишется.
Эпик как требование	BR (бизнес-уровень) или Portfolio Epic (SAFe)	Epic — единица планирования, не требование.
«Тестировать руками»	выборочная проверка (Rule 5 Core) или ручной TC с `type: acceptance`	Расплывчатое; нет проверяемого свидетельства.
«Доделать» (как статус)	`draft` / `review`	Не из закрытого списка жизненного цикла.
TODO во `frontmatter`	запись backward в `ADAPT` (если речь о требовании) или задача в трекере (если о реализации)	Открытые вопросы живут в нужном артефакте, не в комментарии к полю.

При таких находках в локальных артефактах проекта включайте предупреждение на стороне носителя (pre-commit в git, правило валидации в document store).

5. Версионирование глоссария¶

Глоссарий — самостоятельный документ со своей версией. Изменение канонического термина — скачок major-версии (1.0 → 2.0) и сценарий миграции для всех проектных артефактов.

Текущая версия: 1.0-reconciled (согласование фазы 1.5 с standard/04-terms.md §4.14.1).

5.1 Открытые вопросы — закрыты (фаза 1.5, 2026-05-16)¶

Четыре открытых вопроса прежней редакции черновика закрыты согласованием с standard/04-terms.md §4.14.1:

#	Был открытым вопросом	Итог	Источник
1	Канонический язык: латиница (`BR`/`SR`) или русский (БТ/СТ)?	Канон — латиница; русский только в проекции UI (§4.5)	`standard/04 §4.13.3` + `reference/06-ru-style-guide.md §1.3`
2	`TM` как отдельная метка или уточнение `SR`?	`SR` с `level: module` — уточнение, не отдельный тип артефакта	`standard/04 §4.14.1` (устарело `TM`) + §2.1.1
3	AIC ← AAC / AIA / AIC?	`SPEC-AI` (каноника v1.0); AIC — устаревшая метка	`standard/04 §4.14.1` + §2.1.1
4	`INT-TC` отдельный тип или соглашение об именах?	`TC` с `tc-type: contract` — уточнение, не отдельный тип	`standard/04 §4.14.1` (`INT-TC` deprecated) + §2.1.1

5.2 История согласований¶

Дата	Версия	Изменение
2026-05-16	1.0-reconciled	Согласование фазы 1.5 с `standard/04-terms.md §4.14.1`. Устаревшие метки перенесены из таблицы `§14.1` в `§14.1.1`; имена `QG` приведены к канонике v1.0 в §14.4; устаревшие имена → `§14.1`. Обновлены таблицы сопоставления §4.1 и §4.2. Четыре открытых вопроса закрыты (§2.1). Задача: `ru-reconcile-glossary-vs-standard`.
(ранние черновики)	1.0-draft	Наполнение черновика в фазе 7; были открытые вопросы и расхождения с `standard/04 §4.14.1`. История коммита зафиксирована; заменено выпуском 1.0-reconciled.

5.3 Перекрёстные ссылки¶

Стиль редакции v1.0 (reference/06-ru-style-guide.md) — правила русской редакции нормативного текста; §1.9 задаёт канонический перечень терминов параллельно этому глоссарию. При расхождении приоритет формулировок для редакционных проходов — у руководства по стилю.
Канонические определения (standard/04-terms.md); §4.14.1 — сопоставление устаревшие → каноника.

Глоссарий RENAR 1.0-reconciled — часть reference/. См. также 02-schemas.md, 03-ai-risk-register.md, 06-ru-style-guide.md.