Подшаг 0.1 — Nexus Setup: настройка графа Нексусов¶

Первый подшаг бутстрапа. Создаёт живой контекст — Нексусы — до Кортекса. Порядок обязателен: сначала Нексус, потом Кортекс [S1] Часть IX. Без спелого контекста Кортекс усиливает мусор. Источник: operating-model столп 1; [S1] III.1, Принципы 1–2.

🎯 Цель¶

Построить граф из 4 Нексусов (позже — больше типов) с пустыми, но структурированными Узлами (Nodes). Это каркас цифрового профиля продукта, который будет насыщаться в шагах 1–8. На Step 0 Нексусы существуют, но почти пусты — их задача быть готовыми принять контекст, а не быть наполненными.

Типы Нексусов по PAF [S1] III.1: рынка, потребителя, продукта, системы роста, операционной модели, компании. На Step 0 закладываем первые 4 (они нужны шагам 1–8); Нексус опер.модели и компании — при появлении Portfolio Manager.

👤 Роль и ответственность¶

Владелец — Product Ops / Product Architect (настройка Нексусов [S2] III.6). В solo-поде — Product Engineer.

RACI по владению Нексусами (кто реально насыщает каждый):

Нексус	Responsible (насыщает)	Accountable (владеет)	Consulted	Informed
Рынка	Product Engineer	Portfolio Manager	Growth Engineer	весь под
Потребителя	Product Engineer	Product Engineer	AI UX Designer	весь под
Продукта	Product Engineer	Product Engineer	Product Ops	весь под
Системы роста	Growth Engineer	Growth Engineer	Product Engineer	весь под

Обязанность каждого инженера — повышать Context Ripeness своих Нексусов [S1] III.1.

🧩 Структура: 4 Нексуса + Node schema¶

Какие Нексусы создаём на Step 0¶

Нексус	Что хранит	Когда насыщается
Нексус рынка	TAM/SAM/SOM, тренды, конкуренты, Ставки (Bets)	Step 3 (Market)
Нексус потребителя	сегменты, JTBD, боли, гипотеза mNSM	Step 2 (Customer)
Нексус продукта	фичи, ценностное предложение, VP/VPC-узлы	Step 1, 4, 7
Нексус системы роста	каналы, рычаги (Lever), AI-COGS, воронки	Step 5, 6, 8

Node schema (обязательная для каждого Узла) [S1] III.1¶

Каждый Узел Нексуса несёт метаданные:

Node:
  id:                 # уникальный
  type:               # market / customer / product / growth / ...
  содержание:         # факт / гипотеза / метрика
  источник[]:         # ВСЕ источники (URL, [S1]–[S4], RB-STEP-*, интервью, аналитика)
  Confidence Point:   # уровень доверия 0–1 (см. [[operating-model]] столп 4)
  timestamp:          # когда внесён / обновлён
  статус_увядания:    # fresh / ripening / wilting (см. Context Ripeness ниже)
  владелец:           # из RACI выше

⚠️ Узел без источник[] — workslop. Ноль источников = ноль доверия = не попадает в Нексус [S2] III.7.

🤖 Кортекс¶

На этом подшаге Кортекс подключается к Нексусам как RAG-источник, но ещё не генерирует контент (генерация — в шагах 1+). Конкретно:

RAG-слой индексирует все 4 Нексуса; запросы инженера идут через Кортекс → читают Нексус.
Nexus-Builder агент (черновой) — создаёт/обновляет Узлы по команде инженера, проставляя timestamp и запрашивая источник[].
Wilting-детектор (черновой) — помечает Узлы с истёкшим timestamp как wilting (потеря актуальности [S1] III.1).

На Step 0 агенты — скелеты: полностью развиваются в шагах 1–8. Здесь важна связка «Кортекс ↔ Нексус», а не интеллект агентов.

🧠 Человек (метапознание)¶

Человек принимает два решения, которые не делегируются ИИ [S2] III.4:

Какие типы Нексусов нужны поду сейчас (выбор 4 из 6 типов — это конфигурация под контекст компании [S3] IV.4).
RACI владения — кто за какой Нексус отвечает (синхронизация людей — зона человека [S2] III.4).

Инженер верифицирует, что Node schema применяется единообразно (Принцип 2: совместная унификация контекста [S1]). Разрозненные документы вместо Нексуса = анти-pattern [S1] Принцип 1.

📦 Артефакт¶

Граф из 4 Нексусов в едином хранилище (доступ всем стейкхолдерам — Принцип 1 прозрачность [S1]).
Node schema зафиксирована и применена (шаблон Узла готов к заполнению).
RACI-таблица владения — назначены Responsible/Accountable по каждому Нексусу.
Базовые агенты Nexus-Builder + Wilting-детектор подключены (черновой уровень).

🚦 Готовность к след. подшагу¶

✅ Все 4 Нексуса созданы как пустые структуры (Node schema готова).
✅ RACI назначен; каждый Нексус имеет владельца.
✅ Кортекс читает Нексусы через RAG (связка работает).
✅ Wilting-логика определена (как Узел теряет актуальность).
❌ Если Node schema не унифицирована → нет «единого контекста» (нарушение Принципа 2 [S1]) → не переходить к Кортексу.

🛡️ Анти-workslop¶

Не плодить Узлы без источник[] — workslop чистого вида [S2] III.7.
Не дублировать Нексусы — единое хранилище, а не разрозненные документы (Принцип 1 [S1]).
Не откладывать Wilting-логику — без неё Context Ripeness не считается (метрика «увядания» [S1] III.1).
Не путать Нексус с «документацией» — Нексус живой, обновляется событиями; документация как цель упразднена [S2].

🔗 Связи¶

Step 0 — overview — контекст подшага.
operating-model столп 1 (Нексус) + столп 4 (CP) — Node schema, Context Ripeness.
2.cortex-setup — следующий подшаг (Кортекс поверх этих Нексусов).
naming_conventions — термины Nexus / Node / Context Ripeness / Confidence Point.
index Часть III.1 (два полюса опер.модели) и Часть IX (сначала Нексус).

Version: 1.0 · Last updated: 2026-06-20