Примеры и сценарии

Конкретные задачи, которые решает NOUZ — и как именно это работает.

PKM: Большой vault с потерянными связями

Ситуация: 400+ заметок. Папки /ml, /physics, /dev. Идея о том, что энтропия и технический долг — одно и то же явление, живёт на пересечении нескольких папок.

Что делает NOUZ:

# 1. Запускаем и индексируем vault
nouz-mcp
# → Indexed: 412 files

# 2. Переклассифицируем все заметки по содержанию
recalc_signs()
# → 412 notes classified. sign_auto updated.

# 3. Ищем семантические мосты
suggest_metadata("Технический долг.md")
# → bridges:
#   - semantic: "Энтропия.md" (cosine: 0.71)  ← разные домены, один смысл
#   - semantic: "Трагедия общин.md" (cosine: 0.63)

Результат: ИИ предлагает связи, которые вы не проставляли вручную. Вы подтверждаете те, что точны. База начинает понимать себя.

---

Исследование: Отслеживание дрейфа тематики

Ситуация: Модуль «Машинное обучение» начинался как технический, но последние 20 заметок — про философию ИИ и этику. Структура перестала отражать содержание.

Как NOUZ это показывает:

# Получаем формулу узла
format_entity_compact("ML/Машинное обучение.md")
# → sign: E (Engineering), core_mix: {S: 61%, E: 39%}
# → DRIFT WARNING: sign=E, but core_mix says S dominates

core_drift — сигнал: модуль вырос за пределы того, чем задумывался. Можно переименовать, расщепить, или принять эволюцию. NOUZ просто делает это видимым.

---

AI-агент: Knowledge layer из vault

Ситуация: Строим ИИ-агента, которому нужен структурированный контекст — «где это в иерархии и что с этим связано» поверх обычного векторного поиска.

Конфигурация (Claude Desktop):

{
  "mcpServers": {
    "nouz": {
      "command": "python",
      "args": ["-m", "nouz_mcp"],
      "env": {
        "OBSIDIAN_ROOT": "/path/to/vault",
        "EMBED_API_URL": "http://127.0.0.1:1234/v1"
      }
    }
  }
}

Что агент получает:

Пользователь: "Расскажи мне про архитектуру нашей системы мониторинга"

Агент использует NOUZ:
1. list_files(subfolder="infrastructure") → 12 файлов
2. get_children("Infrastructure/Мониторинг.md") → [Prometheus.md, Grafana.md, Alerting.md]
3. format_entity_compact("Infrastructure/Мониторинг.md") → (S2E)[E]{E}
4. read_file каждого потомка → полный контекст

Агент отвечает с реальной структурой вашей базы знаний,
а не с общими словами из обучающих данных.

---

Zettelkasten: Построение DAG с нуля

Ситуация: Новая база знаний. Хочется начать структурировать заметки сразу правильно.

Шаг 1 — Минимальный YAML для заметки:

---
type: квант
level: 4
parents:
  - "[[Название модуля]]"
parents_meta:
  - entity: Название модуля
    link_type: hierarchy
tags:
  - тема
---

Шаг 2 — ИИ помогает расставить:

Агент: "Проанализируй эту новую заметку и предложи где ей место"

suggest_metadata("Новая заметка.md")
→ {
    sign: "E",
    level: 4,
    suggested_parents: ["Архитектура/Паттерны.md"],
    bridges: [
      {type: "semantic", target: "Design/CQRS.md", cosine: 0.74, proposed: true}
    ]
  }

Шаг 3 — Подтвердить или отклонить. NOUZ пишет в файлы только с вашего согласия. proposed: true означает ожидание решения.

---

Dev notes: Документация живого проекта

Ситуация: Заметки о проекте — архитектура, решения, баги, ретроспективы. Хочется чтобы ИИ-ассистент понимал контекст проекта целиком.

Структура vault:

Проект/
├── Архитектура.md       # L3 модуль
├── Решения/             
│   ├── ADR-001.md       # L4 квант — конкретное решение
│   ├── ADR-002.md       
├── Баги/
│   ├── Bug-tracker.md   # L3 модуль
│   ├── Issue-42.md      # L4 квант
└── Ретроспективы/
    └── 2026-Q1.md       # L5 артефакт

Польза: get_children("Проект/Архитектура.md") даёт агенту полную иерархию. suggest_parents("Новый баг.md") находит похожие прошлые случаи. format_entity_compact показывает где в структуре проекта находится любая заметка.

---

Начать просто

Иерархия строится постепенно:

1. Сначала LUCA — добавьте parents в YAML заметок которые хотите связать
2. Потом PRIZMA — когда накопится 50+ заметок, включите эмбеддинги и посмотрите классификацию
3. SLOI по желанию — если хотите строгую 5-уровневую структуру с валидацией

---

Документация живого проекта: когда структура расходится с реальностью

Ситуация: У вас есть большая база — проект, команда, корпоративное хранилище. Разбита по доменам: архитектура, API, бизнес-логика, требования. Всё выглядит аккуратно. Но со временем что-то начинает скрипеть: заметки про архитектуру незаметно обрастают бизнес-логикой, а требования уплыли в сторону технических деталей.

Вручную это не поймаешь. Можно месяцами работать с базой, которая уже не отражает то, чем является на самом деле.

Что NOUZ делает с этим:

core_drift — это не ошибка и не предупреждение в привычном смысле. Это сигнал: намерение, с которым создавался модуль, расходится с тем, о чём его заметки на самом деле. NOUZ вычисляет это автоматически, сравнивая знак домена (то, чем должен быть модуль) с core_mix (то, чем он стал по содержанию).

Модуль "Архитектура сервисов":
  sign: E (Engineering)         ← задан при создании
  core_mix: {S: 58%, E: 42%}   ← реальность из последних заметок

  → DRIFT WARNING

Это значит: последние заметки в этом модуле говорят про системное мышление и принципы — а не про код. Модуль вырос за свои рамки. Или рамки стали тесными.

Что с этим делать — решаете вы. Переименовать. Расщепить на два. Или просто принять, что модуль эволюционировал. NOUZ делает невидимое — видимым.