← к элементу · к схеме

Гайд ЖЦ ИТ-продукта H2

Полный текст

# Жизненный цикл ИТ-продукта H2

## §CHANGELOG v0.15 относительно v0.14 (2026-09-27)

Точечная правка по решению Оператора от 27.09.2026: синхронизация с Гайдом UEPR v0.23 (doc 1429) и Гайдом Аудита v0.2.10 (doc 1430) — узел вынесен в название doc_type UEPR и аудитов. Причины — дефекты реестра документов DEF-UEPR-SLOT-COLLISION-20260926 (doc 1418) и DEF-UEPR-NODE-FILTER-20260927 (doc 1427): поле `node` в реестре отсутствует, чтение узлы не различает.

Изменения: шаблоны адресации Dev-UEPR, Аудита UEPR и Prod-UEPR переведены на узловые doc_type «UEPR <node>»/«Аудит UEPR <node>», нерабочий параметр `node` из шаблонов убран; нормативный адрес Гайда UEPR исправлен на `prod/h2_shared/Гайд UEPR` (фактическое место серии v0.19–v0.23); в «Размещении документов» закреплено хранение UEPR в узловых типах и запрет новых регистраций в общих типах «UEPR»/«Аудит UEPR».

Прочие нормы v0.14, все стадии и правила не изменены. Патч документальный: runtime, wheel, deploy и прежние результаты проверок не менялись и заново не аттестованы.

## §CHANGELOG v0.14 относительно v0.13 (2026-09-25)

Additive-правка по директиве Оператора (патч легаси): после списка ролей добавлен справочный блок «Фактические исполнители ролей» — кто фактически исполняет каждую роль (ПерпКомп/Roo Code/человек) и место оркестрации (внешние оркестраторы за шлюзом ACO). Контракт ролей, стадии, нормы п.15б/17/18а/18б и все прочие правила v0.13 не изменены. Патч документальный: runtime, wheel, deploy и прежние результаты проверок не менялись и заново не аттестованы.

## §CHANGELOG v0.13 относительно v0.12 (2026-09-24)

Точечная правка по решению Оператора от 24.09.2026: с продуктом h2_shared зачётный Live Scenario обязателен. Дополнен п.18а: без успешного прогона зачётного LS (total > 0, failed = 0, полный binding с node, env, release_id, версией, wheel ID и SHA) prod-валидация Ring 0 не считается завершённой; LS не заменяется состоянием реестра, статусом деплоя, heartbeat, самодиагностикой или самоотчётом — отказ или невозможность исполнения LS означает, что приёмка на данном prod-node не завершена. Норма распространяется на каждый active prod-node с h2_shared и на каждый новый объявленный release. Прочие нормы v0.12 и все стадии не изменены. Патч документальный: runtime, wheel, deploy и прежние результаты проверок не менялись и заново не аттестованы.

## §CHANGELOG v0.12 относительно v0.11 (2026-09-23)

Точечная правка по решению Оператора от 23.09.2026: ИИ-Арх действует автономно, патчи ЖЦ вносятся и выпускаются без отдельного запроса разрешения на каждый шаг. Добавлены: п.15б (дисциплина release-cut: после объявления prod-release dev-циклы продолжаются новыми версиями, объявленные байты не меняются, на любой новый prod-node ставится объявленный release); п.17-преамбула (первый ввод нового prod-node: узел в реестре, мост узла отвечает по его Гайду Пользователя, prod-окружение вне dev-деревьев, ИИ-кодер пишет только на Python, неучтённые прежние установки закрываются установкой объявленного release); дополнение п.17 (порядок выпуска набора на один prod-node: ядро → инструменты → валидаторы, каждый продукт проходит полный ЖЦ); п.18а (prod-валидация ядра Ring 0 на prod-node: зачётный Live Scenario назначенным исполнителем test_guide и полная независимая валидация ai_h2_shared_validation, результаты — в prod-UEPR и run-записях ADB); п.18б (окно наблюдения после prod-валидации: транспорт моста узла, журнал ядра через LogQuery, агентский мониторинг; критерий закрытия и учёт находок — как в known_issues). В Критерий готовности добавлен один пункт (prod-валидация Ring 0). Прочие нормы v0.11 и все стадии не изменены. Патч документальный: runtime, wheel, deploy и прежние результаты проверок не менялись и заново не аттестованы.

## §CHANGELOG v0.11 относительно v0.10 (2026-09-22)

Точечная правка по поручению Оператора: prod-запись wheel создаётся один раз после зелёного на dev, а не при каждой установке на prod-node. Добавлен п.15а (однократная регистрация тех же байтов принятого dev-wheel в `env=prod` как отметка «готово к выдаче»); в п.16 закреплено, что dev- и prod-записи одного wheel сравниваются только по SHA-256 и Files ID; в п.17 установка на prod-node идёт из этой prod-записи с регистрацией prod deploy на неё; в Критерий готовности добавлен один пункт. Правка согласована с Гайдом Аудита v0.2.6 (CT-5) и Жизненным циклом пакета h2_shared v0.6. Прочие нормы v0.10 и все 19 стадий не изменены. Патч документальный: runtime, wheel, deploy и прежние результаты проверок не менялись и заново не аттестованы.

## §CHANGELOG v0.10 относительно v0.9 (2026-09-22)

Паспорта тестовых средств и установщика в подготовке, evidence и готовности; 19 стадий сохранены. Онтологию с кодом и фактическим состоянием лично сверяет ИИ-Кодер; ИИ-Архитектор принимает evidence. Полная новая редакция с точечными дополнениями по согласованному поручению Оператора. Изменение документации не является установкой, свежим runtime-тестом или подтверждением автоматизации новых проверок.

## §CHANGELOG v0.9 относительно v0.8 (2026-09-22)

По прямому поручению Оператора внесены две точечные поправки: снят запрет на несколько одновременных задач Кодерам для одной пары `(product, node)` при разделении областей записи и единственном исполнителе изменений общего runtime; явно разрешены быстрые Python DEV-тесты исходников без сборки wheel на каждой итерации. Приёмка установленного неизменяемого артефакта, единственный runtime-набор, независимая валидация и все 19 стадий сохранены. Патч документальный: не подтверждает внедрение кода или успешное прохождение тестов.

## §CHANGELOG v0.8 относительно v0.7 (2026-09-21)

Полная новая редакция по прямому поручению Оператора об очистке битых документных ссылок. Исправлены подтверждённые действующие адреса: Гайд UEPR принадлежит prod/adb_meta, а не prod/ai_docs_broker; в процедуре закрытия дополнительно исправлена среда Онтологии h2_shared на dev и шаблон пользовательского гайда на prod. Для этой редакции заменено 1 JSON-ссылок/шаблонов (1 UEPR, 0 Онтология); изменения не отменяют требований документов.

Разрешимые ссылки заменены проверенными каноническими адресами, а не удалены вместе с нужной зависимостью. Неактивная история и датированные доказательства сохранены без подмены наблюдений. Архив ADB не запрашивался и не изменялся. Исправление документации не означает внедрение нового guard, исправление runtime, повторную валидацию продукта или восстановление недоступных файлов других записей.


## §CHANGELOG v0.7 относительно v0.6 (2026-09-21)

Полная новая редакция по решению Оператора: исправлены действующие ссылки и правила размещения Гайда Пользователя. Для любого продукта этот тип хранится только в prod, независимо от dev-only/dev-and-prod runtime. Постоянная ссылка содержит ровно op, env, product, doc_type и latest:true, без версии, ID и Files URL:

```json
{"op":"get_document","env":"prod","product":"<product>","doc_type":"Гайд Пользователя","latest":true}
```

Поле actor добавляется вызывающей стороной по контракту ADB; это не часть постоянных координат документа. После lookup проверяются возвращённые метаданные и двоичный SHA-256.

Коррекция относится только к документации: runtime, wheel, deploy, сценарии и прежние результаты проверок не менялись и заново не аттестованы. Датированные снимки, ID/версии/SHA в доказательствах и исторические приложения не являются текущими ссылками; они сохраняются как свидетельства своего времени. Прежние требования искать или публиковать пользовательский гайд в dev больше не действуют. Описания старых guard a26/a30 не доказывают сегодняшнюю реализацию; наличие нормативного правила не объявляется успешным runtime-тестом.


**Версия:** v0.12  
**Статус:** ACTIVE  
**Назначение:** единый норматив создания, проверки, выпуска и эксплуатации ИТ-продукта H2.  
**Принцип:** продукт принимается только по фактическим evidence одного release, а не по декларациям, именам файлов или прежним результатам.

## Что нового

В v0.6 добавлен единый обязательный набор действий при новом wheel: регистрация точных байтов, не-editable установка, перезапуск runtime, новый Live Scenario, независимая валидация и обновление evidence. Отдельно закреплено, что prod получает только принятый dev-wheel с теми же Files ID и SHA-256; версия пакета сама по себе не является доказательством тождества wheel. Нормы v0.5 сохранены.

Норма устанавливает единые координаты ADB для документов, фактическую карту продукта из active deploy, доказательную цепочку release и обязательную независимую валидацию специальным агентом `ai_validation`.

## Область применения

ЖЦ применим к каждому продукту H2. Базовые правила обязательны для всех продуктов. Для продукта с пакетируемым артефактом применяются стадии сборки, установки и продвижения артефакта. Вид артефакта, runtime, наблюдение, транспорт и способ запуска определяются документацией конкретного продукта.

`ai_validation` является обязательным специальным агентом независимой валидации принимаемого release. Он не собирает артефакты, не выполняет deploy и не изменяет продукт.

## Термины

- **Продукт** — самостоятельный объект с именем `product`, release и evidence.
- **Узел** — сервер продукта с именем `node`.
- **Dev-node** — единственный узел активной разработки продукта.
- **Prod-node** — каждый иной узел активной эксплуатации продукта.
- **Release** — единая принимаемая совокупность source revision, артефактов, manifest, deploy и evidence.
- **Runtime evidence** — фактическое наблюдение запущенного процесса: node, interpreter, import path, версия, SHA артефакта и время наблюдения.

Для одного продукта на одном узле существует ровно один активный runtime-набор. Dev-среда разработки и установленный dev-артефакт являются слоями одного dev-контура, а не двумя одновременно работающими контурами.

Проверки выполняются в существующем назначенном контуре. Отдельные тестовые БД, схемы-дубликаты, второй runtime-набор и неидентифицированные остановки процессов запрещены.

## Координаты документов ADB

Каждая ссылка на документ задаётся координатами поиска ADB. В нормативном тексте не используются ADB ID, version, имя файла, SHA прошлой версии или неформальная ссылка «актуальный документ».

После получения документа исполнитель скачивает бинарное тело через Files API и сверяет SHA-256 с metadata. Полученные ID, version, file ID и SHA фиксируются в evidence конкретного release.

### Платформенные документы

**Онбординг:**

```json
{"op":"get_document","env":"prod","product":"ai_docs_broker","doc_type":"Онбординг","latest":true}
```

**Гайд Пользователя ADB:**

```json
{"op":"get_document","env":"prod","product":"ai_docs_broker","doc_type":"Гайд Пользователя","latest":true}
```

**Гайд UEPR:**

```json
{"op":"get_document","env":"prod","product":"h2_shared","doc_type":"Гайд UEPR","latest":true}
```

**ЖЦ ИТ-продукта H2:**

```json
{"op":"get_document","env":"prod","product":"adb_meta","doc_type":"Гайд ЖЦ ИТ-продукта H2","latest":true}
```

### Документы продукта

**Онтология:**

```json
{"op":"get_document","env":"dev","product":"<product>","doc_type":"Онтология","latest":true}
```

**Гайд Архитектора:**

```json
{"op":"get_document","env":"dev","product":"<product>","doc_type":"Гайд Архитектора","latest":true}
```

**Гайд Пользователя:**

```json
{"op":"get_document","env":"prod","product":"<product>","doc_type":"Гайд Пользователя","latest":true}
```

**Дорожная Карта:**

```json
{"op":"get_document","env":"dev","product":"<product>","doc_type":"Дорожная Карта","latest":true}
```

**Концепт Развития:**

```json
{"op":"get_document","env":"dev","product":"<product>","doc_type":"Концепт Развития","latest":true}
```

**Стандарт:**

```json
{"op":"get_document","env":"dev","product":"<product>","doc_type":"Стандарт","latest":true}
```

**Live Scenario:**

```json
{"op":"get_document","env":"dev","product":"<product>","node":"<dev_node>","doc_type":"Live Scenario","latest":true}
```

**Отчёт Валидации:**

```json
{"op":"get_document","env":"dev","product":"<product>","node":"<dev_node>","doc_type":"Отчёт Валидации","latest":true}
```

**Dev-UEPR:**

```json
{"op":"get_document","env":"dev","product":"<product>","doc_type":"UEPR <dev_node>","latest":true}
```

**Аудит UEPR:**

```json
{"op":"get_document","env":"dev","product":"<product>","doc_type":"Аудит UEPR <dev_node>","latest":true}
```

**Prod-UEPR:**

```json
{"op":"get_document","env":"prod","product":"<product>","doc_type":"UEPR <prod_node>","latest":true}
```

## Размещение документов

В `dev` находятся Онтология, Гайд Архитектора, Дорожная Карта, Live Scenario, Отчёт Валидации, dev-UEPR и Аудит UEPR.

Гайд Пользователя любого продукта всегда канонически хранится в `prod`, включая dev-only продукты. Он описывает все доступные пользователю среды; наличие prod-runtime не является условием публикации.

На каждом active prod-node существует отдельный prod-UEPR. Начиная с Гайда UEPR v0.23 (doc 1429) UEPR каждого узла хранится в узловом doc_type «UEPR <node>» (например «UEPR light01»), аудиты продукта — в «Аудит UEPR <node>», инвентаризация узла — в «Аудит узла <node>» (Гайд Аудита v0.2.10, doc 1430). Новые регистрации UEPR и аудитов в общих типах «UEPR»/«Аудит UEPR» запрещены; существующие строки остаются историей. Онтология, Гайд Архитектора, Live Scenario и Аудит UEPR не являются обязательными prod-документами.

Каждая новая версия документа создаётся полным текстом. Исторические версии сохраняются в истории и не удаляются из-за появления новой версии.

## Роли

- **Оператор** — задаёт цель и разрешает опасные либо необратимые действия.
- **ИИ-Архитектор** — определяет контур, пишет бриф, проверяет evidence и принимает release.
- **ИИ-Кодер** — выполняет утверждённый бриф на назначенном узле, собирает артефакты, выполняет deploy и формирует evidence.
- **`ai_validation`** — независимый обязательный спец-исполнитель валидации release.

**Фактические исполнители ролей (справка v0.14; контракт ролей выше не меняет):**

- **Оператор** — человек.
- **ИИ-Архитектор** — сессия ПерпКомп (Perplexity Computer) за мостом `owui_perl_bridge`.
- **ИИ-Кодер** — Roo Code в VS Code за мостом `owui_roo_bridge`.
- **`ai_validation`** — постоянный спец-исполнитель H2 (Ring 3 с reasoning-циклом; законное исключение из правила «без LLM» — L1 Концепт ACO §0).
- Мосты между оркестраторами и H2 — шлюз ACO (`ai_connect_orchestrator`, сервис Ring 3): оркестраторы запускают сервисы Ring 3 как готовые тулзы. Отдельной роли «Оркестратор» в ЖЦ нет: постановку задач и планирование выполняет ИИ-Архитектор; Orchestrator ядра `h2_shared` — LEGACY-рудимент.

Кодер не начинает работу без письменного брифа с уникальным TASK_ID. Для одной пары `(product, node)` допускаются несколько одновременных задач разным Кодерам: Архитектор разделяет независимые области работы, закрепляет владельцев файлов/ресурсов, отдельные рабочие папки внутри проекта, общий исходный baseline и зависимости в Дорожной Карте. Пересекающиеся изменения объединяет назначенный интегратор; конкурентная запись в один и тот же общий файл или ресурс запрещена.

Параллельные задачи не создают дополнительных runtime-наборов: установка в общее окружение, изменение БД/конфигурации, управление службами и перезапуски выполняются последовательно одним назначенным исполнителем при проверенном launch-lock. Зачётные Live Scenario, независимая валидация и итоговый UEPR относятся к одному интегрированному неизменяемому baseline; параллельные source-тесты его не заменяют. Архитектор ограничивает число одновременно работающих Кодеров по ресурсам узла и сохраняет защиту активных/чужих задач.

## Фактическая карта продукта

Перед чтением документов, началом работ или аудитом Архитектор определяет карту продукта только по active deploy:

1. получает active deploy в `dev`;
2. получает active deploy в `prod`;
3. фиксирует product, node, env, deploy ID, wheel ID, version, SHA-256 и время каждого deploy;
4. ровно один active dev deploy определяет `dev_node`;
5. отсутствие active prod deploy означает `dev_only`;
6. один или более active prod deploy означает `dev_and_prod`;
7. каждый active prod deploy требует отдельный prod-UEPR той же пары `(product, node, env=prod)`.

Документы подтверждают фактическую карту, но не определяют её.

## Нормальный release-цикл

### Быстрая DEV-проверка и приёмка артефакта

Во время разработки разрешены прямые Python-тесты исходников (`python -m pytest`, `unittest` или целевой test runner) без сборки и переустановки wheel на каждой итерации. Для DEV-тестов допустим source import либо editable только в изолированном тестовом Python-окружении внутри текущего проекта, не в принимаемом установленном runtime. Такое окружение служит для тестового процесса и не является разрешением создавать второй service/listener runtime-набор, отдельную тестовую БД или схемы-дубликаты.

Каждый DEV-прогон фиксирует TASK_ID, source revision/хеш изменённых исходников, interpreter, фактический module path, команду, результаты и `mode=source_dev`; успешный результат подтверждает проверку исходников, но не готовность wheel или release. При работе с назначенным живым dev-контуром сохраняются правила единственного writer, ограниченных побочных эффектов и защиты активных задач.

Для приёмки кандидата обязательна отдельная проверка точных байтов зарегистрированного артефакта после обычной noneditable установки: фиксируются wheel ID/SHA, release ID, dependency identity и runtime evidence; проверяются import path без подмены исходниками, полнота package data/ресурсов, entry points и зависимости. После этого выполняются зачётный Live Scenario и независимая валидация по стадиям 6–11. Это правило приёмки H2, а не требование собирать wheel перед каждым DEV-тестом.

Для ускорения уже собранный неизменившийся wheel можно повторно использовать в совместимых тестовых окружениях; совпадение SHA и совместимость обязательны. Новый код или изменившиеся зависимости требуют новой применимой приёмки; старый wheel не доказывает новые исходники. Запрет Оператора на сборку wheel не мешает DEV-проверкам, но при отсутствии подходящего зарегистрированного артефакта итоговый release остаётся BLOCKED, а не получает GREEN по исходникам. Формат wheel сам по себе не является обещанием ускорения исполнения Python-кода.

### Подготовка

До постановки реализации Архитектор определяет тестовые средства и способ установки продукта. Повторно используемые тестовый стенд и установщик учитываются как инструменты продукта: назначение и ответственный находятся в Онтологии, фактический паспорт и доступные артефакты в UEPR. Если инструмент ещё предстоит создать, это отдельный незавершённый пункт Дорожной Карты с владельцем и критерием приёмки, а не основание объявить инструмент существующим.


1. Архитектор создаёт либо обновляет Дорожную Карту продукта в `dev`.
2. Кодер получает бриф с TASK_ID, назначенным node, ожидаемым release и критериями evidence.
3. До запуска runtime Кодер подтверждает единственность контура, назначенную БД, отсутствие второго runtime-набора и работоспособность launch-lock.

### Сборка и dev-приёмка

4. Кодер фиксирует неизменяемые `source.ref` и `source.revision`, затем собирает артефакт на dev-node.
5. Для каждого компонента фиксируются версия, SHA-256 и Files ID. Создаётся единый release manifest:

```json
{
  "release_id":"<uuid>",
  "product":"<product>",
  "source":{"ref":"<immutable reference>","revision":"<immutable revision>"},
  "components":[
    {"name":"<component>","version":"<version>","sha256":"<64hex>","owui_file_id":"<uuid>"}
  ],
  "built_on":"<dev_node>",
  "built_at":"<UTC ISO-8601>"
}
```

До установки и приёмочного Live Scenario артефакт загружается и регистрируется в ADB. Полученный `wheel_id` связывается с его SHA-256 и release manifest. Регистрация артефакта не означает успешную валидацию или приёмку release.

6. Кодер устанавливает артефакт обычной не-editable установкой в runtime dev-контура и запускает единственный runtime-набор.
7. Кодер фиксирует runtime evidence:

```yaml
observed_at: "<UTC ISO-8601>"
product: "<product>"
env: "dev"
node: "<dev_node>"
release_id: "<uuid>"
sys_executable: "<absolute path>"
module_file: "<absolute import path>"
package_version: "<observed version>"
wheel_sha256: "<64hex>"
```

8. Архитектор выполняет Guide-Runtime Parity: получает Гайд Пользователя продукта по координатам ADB, подтверждает SHA-256 бинарного тела, сверяет операции, обязательные поля и примеры вызовов с runtime.
9. Кодер выполняет Live Scenario по подтверждённому пользовательскому гайду. Зачётный Live Scenario выполняется после установки зарегистрированного артефакта. Проверки исходников до сборки являются предварительными и не заменяют этот прогон. Зачётный run содержит:

```yaml
run_id: "<unique ID>"
product: "<product>"
env: "dev"
node: "<dev_node>"
release_id: "<uuid>"
product_version: "<version>"
wheel_id: "<ADB wheel ID>"
wheel_sha256: "<64hex>"
source_revision: "<immutable revision>"
total: "<positive integer>"
passed: "<integer>"
failed: 0
verdict: "passed"
evidence_ref: "<immutable evidence>"
```

10. Наблюдение runtime остаётся активным во время проверки и публикует согласованное актуальное состояние.
11. `ai_validation` получает release evidence и выполняет полный применимый чек-лист. Его Отчёт Валидации связан с тем же release ID, dev-node, wheel ID, wheel SHA и ненулевым total.
12. Для продукта `ai_validation` self-validation использует те же evidence release. Архитектор отдельно принимает source, wheel, runtime, Live Scenario, UEPR и результаты self-validation.
13. После последовательного успешного Live Scenario и `ai_validation` Кодер завершает учёт release в ADB: фиксирует результаты приёмки, release manifest, dev deploy и product state, связанные с ранее зарегистрированным артефактом.
14. Кодер выпускает полный dev-UEPR и Аудит UEPR. Dev-UEPR доказывает цепочку source → dev artifact → dev deploy → dev runtime → Live Scenario.

### Обязательные действия при новом wheel

Новый wheel — это wheel с новым SHA-256, даже если его строка версии не изменилась. Нельзя считать новый wheel обновлением только по имени файла или версии пакета.

При каждом новом wheel Кодер выполняет один связанный набор действий:

1. создаёт новый `release_id`, фиксирует неизменяемые `source.ref` и `source.revision`, SHA-256, размер, Files ID и версию wheel в release manifest;
2. загружает и регистрирует именно эти байты в ADB до установки; идентификатор зарегистрированного wheel и его SHA сохраняются в manifest;
3. устанавливает зарегистрированный wheel в назначенный runtime обычной не-editable установкой. Runtime, который импортирует исходники, editable-install, другой virtualenv или wheel с иным SHA, не принимается;
4. перезапускает единственный runtime-набор и снимает новое runtime evidence: node, env, `sys.executable`, путь импортируемого модуля, версию, `release_id` и SHA установленного wheel;
5. выполняет зачётный Live Scenario на этом runtime. В run обязательно совпадают node, env, `release_id`, версия, wheel ID и wheel SHA, а `total > 0` и `failed = 0`;
6. передаёт тот же набор evidence в `ai_validation`; выпускает новый Отчёт Валидации, dev-UEPR и Аудит UEPR. Старые успешные отчёты не подтверждают новый SHA;
7. только после успешных пунктов 1–6 обновляет active dev deploy и product state. Если изменился пользовательский контракт, одновременно обновляет Гайд Пользователя и повторяет Guide-Runtime Parity; если изменились назначение, состав или границы продукта, одновременно обновляет Онтологию и Гайд Архитектора.

Исторические wheel, deploy и документы не удаляются: они остаются evidence прежних release. В актуальном product state, active deploy, runtime evidence, Live Scenario, Отчёте Валидации, UEPR и Аудите UEPR должен быть указан один и тот же принимаемый `release_id` и SHA wheel.

### Продвижение и prod-приёмка

15. Архитектор разрешает promote только если dev evidence полностью подтверждены, а dev-UEPR и Аудит UEPR не содержат обязательных `FAIL` или `BLOCKED`.
15а. Сразу после разрешения по п.15 Кодер **один раз** регистрирует те же байты принятого dev-wheel в `env=prod` (`register_wheel`: те же `version`, `sha256`, `size`, `filename`, `owui_file_id`; в `comment` указываются dev `wheel_id`, `release_id` и версии dev-UEPR, Live Scenario, Отчёта Валидации и Аудита UEPR). Эта prod-запись является отметкой «готово к выдаче»; для каждого нового prod-node её повторно не создают.
15б. Объявленный prod-release фиксируется в Дорожной Карте/актуальном product state как текущий prod-declared release. После п.15а dev-циклы продолжаются с новыми версиями и не изменяют объявленные байты; на любой новый prod-node ставится именно объявленный release, а не последний dev. Обновление объявленного release — только через новый полный dev-цикл приёмки и новую prod-запись по п.15а.
16. В prod передаются только те же байты wheel из принятого dev release manifest: совпадают release ID, Files ID и SHA-256. Пересборка для prod, wheel с другим SHA и установка wheel, не прошедшего dev-приёмку, запрещены. Prod-запись wheel по п.15а — учётная копия тех же байтов, а не новый артефакт; тождество dev- и prod-записи проверяется только по SHA-256 и Files ID, их `wheel_id` различаются и не сравниваются.
17-преамбула. Первый ввод нового prod-node. Перед первой установкой на prod-node: узел присутствует в реестре узлов; мост узла отвечает по его Гайду Пользователя (с явным node/workspace, без подмены операций); определено prod-окружение — interpreter/venv и module path вне dev source root, dev-workspace и dev-virtualenv; ИИ-кодер на узле использует только Python (правило Оператора); ранее неучтённые установки продукта на узле закрываются установкой объявленного release и регистрацией deploy (не удалением и не молчанием).
17. Для каждого prod-node Кодер устанавливает wheel из prod-записи по п.15а обычной не-editable установкой, регистрирует prod deploy на эту prod-запись, перезапускает единственный runtime-набор и фиксирует новое runtime evidence. Runtime evidence доказывает node, env, interpreter, module path, версию, `release_id` и SHA wheel; source/editable import запрещён. Путь interpreter, virtualenv и импортируемого модуля не может лежать в dev source root, dev-workspace или dev-virtualenv. При выпуске набора продуктов на один prod-node порядок установки: ядро → инструменты → валидаторы; каждый продукт набора проходит свой полный ЖЦ, приёмка набора на узле завершается только после приёмки всех его продуктов.
18. После prod deploy Кодер выпускает prod-UEPR. Source и dev Live Scenario в prod-UEPR имеют `not_applicable`; prod deploy, установленный wheel и фактический prod runtime должны совпадать с принятым dev release manifest.
18а. Prod-валидация ядра (Ring 0) на prod-node: после установки ядро проверяется зачётным Live Scenario силами назначенного исполнителя (test_guide) и полной независимой валидацией (ai_h2_shared_validation); результаты фиксируются в prod-UEPR и run-записях ADB. Dev Live Scenario в prod-UEPR остаётся `not_applicable` по п.18. Зачётный Live Scenario обязателен (правило Оператора от 24.09.2026): без успешного прогона (total > 0, failed = 0, полный binding с node, env, release_id, версией, wheel ID и SHA) prod-валидация Ring 0 не считается завершённой; LS не заменяется состоянием реестра, статусом деплоя, heartbeat, самодиагностикой или самоотчётом; отказ или невозможность исполнения LS означает, что приёмка ядра на данном prod-node не завершена. Норма действует для каждого active prod-node с ядром h2_shared и для каждого нового объявленного release.
18б. Окно наблюдения после prod-валидации: транспорт моста узла (health/heartbeat по Гайду моста), журнал ядра через LogQuery, агентский мониторинг продукта. Находки окна учитываются как known_issues соответствующего UEPR; закрытие окна — по решению ИИ-Арха на основе фактических метрик, а не истечения времени.
19. Архитектор проверяет соответствие release manifest, active deploy, runtime evidence и prod-UEPR на каждом prod-node: SHA и Files ID active prod-wheel равны компоненту принятого dev release, этот dev-wheel зарегистрирован и принят до prod deploy, а фактические пути prod runtime не принадлежат dev-контуру. При несовпадении prod не получает GREEN.

## Критерий готовности

Для каждого обязательного инструмента следующий уполномоченный исполнитель должен иметь возможность найти паспорт через ADB, получить все необходимые несекретные входные данные и воспроизвести безопасную проверку без обращения к памяти предыдущей сессии. Недоступный или неполный обязательный инструмент блокирует готовность соответствующего этапа; DEV-исправления при этом могут продолжаться.


Release готов к общему GREEN, когда одновременно выполнены условия:

- фактическая карта продукта определена однозначно;
- все обязательные документы получены по координатам ADB и подтверждены SHA-256 бинарного тела;
- source revision, release manifest, SHA артефакта, deploy и runtime evidence относятся к одному release;
- dev runtime и prod runtime импортируют продукт из установленного артефакта;
- при наличии prod его active wheel совпадает по Files ID и SHA-256 с принятым dev-wheel того же release;
- Live Scenario имеет `total > 0`, полный binding и успешный verdict;
- `ai_validation` завершил обязательную независимую валидацию;
- dev-UEPR и Аудит UEPR подтверждают dev-цепочку;
- каждый active prod-node имеет отдельный prod-UEPR;
- ядро на каждом active prod-node прошло prod-валидацию Ring 0 по п.18а (зачётный Live Scenario исполнителем и независимая валидация);
- prod-запись wheel создана после принятия dev release, и её SHA-256 и Files ID равны принятому dev-wheel;
- evidence каждого шага существует и относится к принимаемому release.

## Evidence и обновление

Каждый зачётный прогон и установка фиксируют `asset_id`, точную версию и контрольную сумму использованного инструмента, входные данные, проверенный release и результат. История чата и временный workspace не являются единственным допустимым местом хранения инструмента или инструкции.


Кодер хранит evidence каждого шага в `_tasks/<TASK_ID>/evidence/`. Финальный отчёт Кодера содержит выполненные действия, фактические результаты, ссылки на evidence и координаты созданных либо обновлённых документов.

Новая source revision, новый SHA артефакта, новый deploy, изменение runtime, изменение Live Scenario или изменение пользовательского контракта требуют нового релизного цикла и новых документов соответствующей области.

§END