12. Миграция на v1.1¶
Шаг 4 процедуры §13.9.3 для волны v1.1 (ADR-015…ADR-026, GitLab #30–#54). Для внедрений, заявивших соответствие RENAR v1.0. Выпуск minor-версии — немедленный триггер повторной оценки (§13.7.3): заявление v1.0 действует до переоценки, но не переносится на v1.1 автоматически.
Не путать с 10-migration-v1 — там историческая миграция v0 → v1.0; здесь — правки одной minor-волны с сохранением идентификаторов и трассируемости.
1. Что изменилось — карта волны¶
| # | Правка | Где | Основание | Класс для внедрения |
|---|---|---|---|---|
| 1 | Комплект описания — единица утверждения, версии и верификации; BR / SR / SPEC / TC-норма без status / version; set-version N.M, линейная история, запись версии |
§10.5, §6.5.4, §6.6.4, §8.8, §9.9 | ADR-024, #46, #48 | ломающая (схема) |
| 2 | QG-0 / QG-1 / QG-2 — объекты: версия комплекта / реализация TC / версия на версии продукта; automation.set-version, last-run.set-version |
§10.3, §9.3 | ADR-024 | ломающая (схема) |
| 3 | §13.3.5 — покрытие парами TC проверяется при QG-0 версии комплекта (coverage-presence) |
§13.3.5, §10.11.1 | ADR-024, ADR-025 | обязательное положение — переоценка |
| 4 | Манифест: set-version, confirmation: first-party \| second-party |
§13.4.2 | ADR-024, ADR-017 | ломающая (манифест) |
| 5 | SPEC-UC — двенадцатый тип (role: human \| agent, steps[].ref); ссылка шага на утверждение в SPEC-UI / SPEC-PROC; ux-TC на действие через интерфейс |
§8.3, §8.5.12, §9.8 | ADR-018, #35, #34 | закрытый список №7; новые правила |
| 6 | MW — запись ручного прохода (класс свидетельств) | §9.20, reference/02 §8.3 | ADR-018, #34, #50 | добавляющая |
| 7 | Подтверждение первой стороной — концепт на входе, ACTZ / AT беспредметны; совмещение ролей | §1.4.4, §5.5.5 | ADR-017, #33 | добавляющая (вид применимости) |
| 8 | Переиспользуемый компонент — система в собственном дереве; assumptions[], applies-to, ребро uses[] |
§6.14, §10.11.1 | ADR-016, #30 | добавляющая |
| 9 | implements[] — обязательное положение §13.3.8 |
§13.3.8 | #30 | обязательное положение — переоценка |
| 10 | Реестр экранов — перечень в теле SPEC-ARCH, screens[] в SPEC-UI, правило покрытия; определение экрана |
§8.5.1, §8.5.6.1, §10.7.2 | ADR-023, #42, #45, #54 | добавляющая (структурная полнота) |
| 11 | Полнота охвата обязательного тела SPEC | §8.4.1 | ADR-023, #42 | добавляющая |
| 12 | SPEC-ARCH и SPEC-SEC обязательны и непусты на уровне system |
§8.3, §10.7.3 | модель 3.3 | добавляющая (структурная полнота) |
| 13 | Контролируемая форма утверждения SR — шесть форм (рекомендация) | §6.6.3.1 | ADR-022, ADR-026, #37 | рекомендация |
| 14 | Язык описания — глава 15: операторы, глоссарная дисциплина, запрещённые конструкции, атомарность; обязательна с RENAR-2 |
глава 15, §11.5, §1.7.5 строка 17 | ADR-026, #51 | обязательна с RENAR-2 |
| 15 | automation.status — два значения (automated / manual-pending с дедлайном и причиной) |
§9.3 | #50 | ломающая (схема) |
| 16 | AR фиксирует модель основного агента (primary.*); состав ai-provenance по канону |
§4.10.1, §12.3 | #38, #44 | схема (ai-provenance) |
| 17 | Калибровка порогов метрик — по условию достаточности данных | §12.3 | ADR-020 | добавляющая |
| 18 | Измеритель невырожденности нового обязательного контроля | §13.9.4 | ADR-021, #40 | процедурная |
| 21 | Адрес утверждения <id>#n: verifies[].statement в TC (обязателен при более чем одном утверждении артефакта), ref шага в форме адреса, coverage-presence по адресам |
§15.1.1, §9.3, §8.5.12.1 | ревью v1.1 | добавляющая (схема TC) |
| 20 | Норма и процесс: стандарт нормирует артефакты, жизненные циклы и правила, не порядок работ; агентские редакции — предусловия вместо шагов | §1.2.1, §1.3 п. 7, §7.6.1, §11.11 | ADR-027, #55 | редакционная (граница нормы) |
2. Что делать внедрению — по классам¶
2.1 Ломающие правки схемы (строки 1, 2, 4, 15)¶
- Снять
statusиversionс BR / SR / SPEC / TC-норм. Состояние артефакта выводится из версии комплекта (§6.5.4). Скрипт миграции: удалить поля, зафиксировать первую версию комплекта1.0записью версии (§10.5.4) с подписью Архитектора, включив в неё все артефакты, бывшиеapproved+; артефакты вdraftостаются в черновике комплекта. - TC:
verifies[].version/requirement-version→ удалить; добавитьautomation.set-versionиlast-run.set-version= версия комплекта, на которой реализация создана и прогнана;automation.status→automatedлибоmanual-pendingсmanual-pending-until/manual-pending-reason. Проверка:scripts/validate-schema-examples.js(правилаverifies-legacy-version,invalid-tc-type). - Манифест: добавить
set-version(текущая утверждённая версия комплекта) иconfirmation(second-partyпри наличии заинтересованной стороны,first-party— при концепте на входе, §1.4.4);renar-version: "1.1". - Хуки носителя: переходы поартефактных состояний заменить точками контроля версии комплекта (§10.11.1):
coverage-presence,implements-edge,uses-edge validation; QG-1 — только допуск реализации TC.
2.2 Обязательные положения (строки 3, 9) — переоценка¶
Заявление v1.0 обязано быть переоценено (§13.7.3): §13.3.5 теперь проверяется на версии комплекта целиком (каждое утверждение версии — пара TC-норм в той же версии), §13.3.8 требует implements[] для BR подсистем. Самооценка — reference/08, ключи mandatory-clauses-confirmed не переименованы.
2.3 Добавляющие правки (строки 5–8, 10–12, 16–18)¶
- SPEC-UC: сценарии, ранее жившие как user journey SPEC-UI или happy path SPEC-PROC и сшивающие несколько SR / SPEC, — вынести в
SPEC-UCсroleиrefна каждом шаге; шаги безref— нарушение структурной полноты. Утверждения SPEC-UI о действии через интерфейс — покрытьux-TC. - Реестр экранов: в SPEC-ARCH уровня
systemдобавить раздел «Перечень экранов» из описания (не из маршрутов кода); в каждом SPEC-UI —screens[]; непокрытый экран блокирует утверждение версии. Система без интерфейса пишет «интерфейса нет». - SPEC-ARCH / SPEC-SEC: при отсутствии — создать; молчание ТЗ о безопасности закрывается собственным SPEC-SEC, при наблюдаемых клиентом последствиях — через ACTZ.
- Компонент: библиотеки и платформы, описанные как подсистемы или «четвёртый уровень», — перевести в систему в собственном дереве с
uses[]у потребителей (§6.14); путь B или C — по структуре организации. - Первая сторона: внедрения без заинтересованной стороны (прежний §1.5.4) при письменном концепте — вид применимости §1.4.4,
confirmation: first-party; без концепта — вне области применения. - Запись ручного прохода (MW): ручные прогоны сценариев оформлять записью
MW-NN; постоянный ручной прогонux-TC не вводится. - ai-provenance / AR: привести
generated-byк формату с версией, добавитьprimary.*в AR.
2.4 Язык описания (строка 14) — обязателен с RENAR-2¶
Для заявлений RENAR-2+: нормативные разделы артефактов — по §15.2–§15.5. Порядок: (1) операторы — заменить синонимы («обязан», «необходимо», «может») на пять слов списка; (2) термины — свести к одной форме по цепочке, расхождения — находки terminology; (3) конструкции §15.4 — переформулировать; (4) атомарность — разбить утверждения, на которые нельзя написать ровно одну пару TC. Формы §15.6 — рекомендация; утверждённые версии задним числом не переформулируются — правки входят следующей минорной версией комплекта.
Строка 20 действий не требует: если ваш производственный процесс отличается от сценариев руководств, он соответствует стандарту, пока выполнены предусловия артефактов (агентская редакция, раздел 4); собственные артефакты и правила — declared-stricter.
3. Порядок работ¶
| Шаг | Что | Проверка |
|---|---|---|
| A | Инвентаризация: артефакты со status / version, TC с requirement-version, SPEC-UI без screens[], SPEC-ARCH без перечня, отсутствующие SPEC-ARCH / SPEC-SEC |
скрипт по frontmatter |
| B | Первая версия комплекта 1.0: запись версии, подпись Архитектора; снятие полей |
validate-schema-examples, структурная полнота §10.7.2 |
| C | TC: set-version, automation.status из двух значений; QG-1 как допуск реализации |
прогон, last-run.set-version = 1.0 |
| D | Добавляющие правки §2.3 — следующей минорной версией комплекта 1.1 |
QG-0 версии: coverage-presence, screens, uses |
| E | Язык описания (RENAR-2+) — по мере правки артефактов | состязательный обзор, статическая проверка |
| F | Манифест renar-version: "1.1", set-version, confirmation; самооценка reference/08; переоценка заявления |
§13.7.3 |
4. Частые ловушки¶
- Версия комплекта ≠ версия продукта.
set-version— версия описания; версия продукта живёт в записи верификации (§10.5.4). - Минор при всяком изменении. Правило «крупное или мелкое» не принимается: любое утверждённое изменение — минор; мажор — решение на рубеже с полным аудитом.
- Реестр из кода. Перечень экранов по маршрутам реализации нарушает §2.3.1; экран в коде без записи — дрейф и обратная находка.
- Прописные операторы. В русской редакции артефактов запрещены (reference/06 §2.1 п. 4); однозначность даёт закрытость списка.
5. Откат¶
Правки v1.1 не удаляют данных: снятые поля status / version восстановимы из истории носителя (V1); запись версии комплекта — добавляющая. Возврат к заявлению v1.0 — откат манифеста и повторная самооценка по v1.0.
6. Связанные документы¶
- ADR-024 (пакетная модель; §9 — места правок по задачам волны) и ADR-026 (язык описания) — архив решений стандарта, доступен в репозитории
- CHANGELOG — запись v1.1
- reference/08 — самооценка соответствия
Guide RENAR 1.1 — renar.tech