obsidian-untangle-knot

name

obsidian-untangle-knot

description

Разгрузка hub-заметки в Obsidian, на которую ссылается слишком много заметок (in-clubok). Главный сигнал клубка — высокий in-degree (десятки–сотни входящих ссылок), out-degree — вспомогательный. Скилл создаёт под-MOC под существующие категории hub и **перенаправляет входящие ссылки из ресурсных заметок** на конкретный под-MOC вместо общего. Оригинальный MOC сохраняется как точка входа — на него по-прежнему можно ссылаться, когда категория неясна. Используй этот скилл всегда, когда пользователь говорит: «распутай клубок», «разгрузи MOC X», «слишком много ссылок на X», «перепривязать заметки», «X разросся», «карта стала бесполезной», «не вижу структуры в MOC», «слишком много входящих/исходящих ссылок», «обработай хаб-заметку», «найди мои hub-заметки», «свалка ссылок», «карта-помойка». Также применяй, когда из контекста видно, что речь о перегруженном узле графа, даже если пользователь не назвал его hub-ом.

obsidian-untangle-knot

Базовая идея

В персональной базе на одни и те же MOC ссылаются десятки и сотни заметок — это естественно: когда добавляешь статью, книгу или новую идею, проще сослаться на общий [[DevOps]], чем искать конкретную подкарту. Со временем общий MOC превращается из карты в свалку backlinks: открываешь — и тонешь в шуме.

Out-links на hub растут медленно (это всё-таки карта, её осознанно поддерживают). А in-links — стихийно и быстро. Поэтому главный сигнал клубка — высокий in-degree, не out.

Скилл:

1. Находит/принимает hub и считает in/out
2. Опирается на уже существующую структуру hub (подзаголовки, явные категории) как на готовые точки приземления — не выдумывает новые категории, когда их не просили
3. Создаёт под-MOC под каждую категорию
4. Главное действие: проходит по входящим ссылкам из ресурсных заметок и переключает их с общего MOC на подходящий под-MOC
5. Оригинальный MOC остаётся — он по-прежнему правильная точка входа для случая «не знаю точнее куда сослаться»

до:                          после:
                             [hub] (~ остаётся, но in-links реже)
[hub] ←── 200 in-links       ├── [под-MOC A] ←── 60 in-links (бывших общих)
  ├── 22 out-links           ├── [под-MOC B] ←── 40
                             ├── [под-MOC C] ←── 30
                             └── [под-MOC D] ←── 25
                             (общие, неклассифицированные ~45 — на hub)

Базовые правила (PARA, теги, шаблоны, стиль, именование) — в .agents/rules/. Особенно: knowledge-structures.md (MOC), note-types-frontmatter.md (frontmatter), workflows.md (протокол план → подтверждение → действие), file-naming.md (имена).

Корневая папка хранилища (<vault>/): задаётся при установке (--vault или env BEAR_VAULT). См. .agents/rules/vault-struct.md. Язык вывода: Русский, технические термины — на английском.

---

Когда использовать и когда нет

Ситуация	Скилл
Одна заметка/MOC, перегруженная связями	этот скилл
Содержимое одной заметки нужно разбить на атомарные	obsidian-split-note
Конспект лекции — вынести концепты	obsidian-refactor-lecture
Сверка одной заметки на противоречия и пробелы	obsidian-note-critic
Inbox-заметки — разобрать и разложить	obsidian-refactor-inbox
Обновить frontmatter одной заметки	obsidian-enrich-note
Визуальная карта callout-ов одной заметки	obsidian-note-canvas-map

Разница с obsidian-split-note: тот скилл разбивает содержимое одной заметки на атомарки. Здесь мы разбиваем связи (граф), а не текст — тело заметки переписывается в оглавление, новые атомарки не создаются.

---

Алгоритм

1. Выбор hub-заметки

Два режима.

Точечный — пользователь сразу назвал заметку («разгрузи [[DevOps]]»). Найди файл по имени:

fd -t f "DevOps.md" .

Если имён несколько — спроси, какой именно.

Discovery — пользователь хочет найти кандидатов («найди мои hub-заметки», «где у меня перегруз»). Прогон по 03. Ресурсы/07. Карты/ (по умолчанию) или другой папке по запросу:

# Подсчёт out-links: количество [[wikilink]] в теле + frontmatter
for f in "03. Ресурсы/07. Карты/"*.md; do
  out=$(rg -o '\[\[[^\]]+\]\]' "$f" | wc -l)
  echo "$out  $f"
done | sort -rn | head -10

# Подсчёт in-links: сколько раз на заметку ссылаются
rg -c -F "[[Имя заметки]]" .

Покажи top-10 по in + out и спроси, какую разгружать. Пороги — см. ниже в шаге 2.

2. Подсчёт ссылок и диагностика

In-links — три разных потока, не одна метрика. Это критически важно: ссылка из up: соседа и ссылка в теле статьи — это разные явления с разной стратегией обработки. Игнорировать различие — значит работать неполно.

Поток	Что это	Как искать	Перепривязка
A. Out-соседи hub	Заметки, на которые ссылается hub (из тела или down)	Парсинг тела/frontmatter hub	Итерация 1 (каркас)
B. Up-children	Заметки, у которых up: [[Hub]] в frontmatter, но они не упомянуты в теле hub	Скан frontmatter всех заметок	Итерация 1 (каркас) — не пропускай!
C. In-links в телах	Контекстные упоминания [[Hub]] в теле других заметок	rg -F "[[Hub]]" по телам	Итерация 2 (тяжёлая, опциональная)

Подсчёт:

# Поток A: out-degree
# В теле hub — wikilinks через regex \[\[([^\]\|#]+)
# В frontmatter hub — up, down, other, links, sources

# Поток B: up-children — ТОЛЬКО из поля `up:`, не из других полей frontmatter!
# Грубый grep по frontmatter ловит лишнее: [[Hub]] может быть в other/links/category/sources —
# это разная семантика, перепривязывать НЕЛЬЗЯ.
# Парсинг точный — только многострочный или однострочный up:
python3 - <<'PY'
import os, re
res = []
for dp, _, fns in os.walk('.'):
    for fn in fns:
        if not fn.endswith('.md'): continue
        p = os.path.join(dp, fn)
        try:
            with open(p, encoding='utf-8') as f: c = f.read(4000)
        except: continue
        m = re.match(r'^---\n(.*?)\n---', c, re.DOTALL)
        if not m: continue
        fm = m.group(1)
        # Многострочный (up:\n  - "[[X]]"\n  - ...)
        block = re.search(r'^up:\s*\n(.*?)(?=^[a-zA-Z_]+:|\Z)', fm, re.M|re.S)
        if block and re.search(r'-\s*"?\[\[Hub\]\]"?', block.group(1)):
            res.append(p); continue
        # Однострочный (up: "[[X]]")
        s = re.search(r'^up:\s*(.+)$', fm, re.M)
        if s and '[[Hub]]' in s.group(1):
            res.append(p)
print(len(res))
PY

# Поток C: in-links в телах (общий счёт)
rg -l -F "[[Hub]]" --type md . | wc -l
rg -l -F "[[Hub]|" --type md . | wc -l  # с pipe-алиасами

Зафиксируй:

• A = unique out-degree
• B = unique up-children
• C = unique in-links в телах
• Пересечение A ∩ B (out-сосед, который также имеет up: [[Hub]]) — обрабатывается в потоке A (он покрывает оба случая)

Почему это критично: Поток B — самая «забытая» нагрузка. Заметка имеет up: [[Hub]], но не упомянута в теле hub. Если разгружать только поток A, эти заметки остаются с устаревшей категоризацией.

Важно про другие поля frontmatter:

[[Hub]] может встречаться в нескольких полях frontmatter — у каждого своя семантика:

Поле	Что это	Трогаем при разгрузке?
up	Родитель в иерархии PARA/MOC	Да — это и есть поток B
other	Горизонтальная связь, родственная тема	Нет — это контекстная связь, не категория
links	Внешние ссылки или родственные wikilinks	Нет — навигация, не категоризация
category	Пользовательское поле каталога (книги/статьи/видео — «полка»)	Нет — это категоризация по типу контента, не по теме
sources	Источники (литературные wikilinks или текстовые)	Нет, никогда — летопись источников
down	Дочерние заметки (в hub-е)	Часть потока A

Если перепутать и тронуть [[Hub]] в other/links/category — сломаем семантику. Скилл должен точно парсить YAML и работать только с полем up.

Порог «клубка» (по in-degree):

in-degree	Диагноз	Действие
≥ 100	Сильный in-клубок	Распутываем (этот скилл)
50–100	Зреющий in-клубок	Можно распутать; спроси пользователя
20–50	Слабый клубок	Распутывание возможно, но прирост от перепривязки невелик
< 20	Не клубок	Скорее всего, рано

Out-degree влияет на возможность распутывания:

• N < 5 при высоком in → распутывать некуда, под-MOC не из чего лепить. Скилл отказывается, предлагает obsidian-ingest или obsidian-note-critic.
• N = 5–10 → можно слепить 2–3 категории, если они уже намечены подзаголовками
• N > 10 → есть пространство для нормальной категоризации

Высокий out при низком in (out=30, in=5) — это out-клубок, что в твоей базе встречается редко (out растёт медленнее). Сценарий другой: переписывается тело hub в оглавление, под-MOC создаются для красоты. Это «лёгкая ветка» скилла, см. особый случай ниже.

3. Чтение соседей (без изменений)

Для каждого out-соседа hub — короткий read и классификация:

• Существует ли файл? Если wikilink dangling — это не сосед, а пустая ссылка. Фиксируй в отдельный список «dangling out-links», в перепривязку up не идёт.
• Имя файла и путь
• Тезис (одна фраза — берётся из первой осмысленной строки тела или из aliases)
• Структурный тег и папка PARA
• confidence (если есть)
• up — самое важное. От его значения зависит ветка перепривязки в шаге 6.2:
  • up пустой → добавляем под-MOC
  • up содержит [[Hub]] → заменяем на под-MOC
  • up содержит [[Какой-то – Альтернативный – под-MOC]] который существует как файл → не трогаем, у заметки уже есть категоризация (см. ниже)
  • up содержит wikilink, который не существует (dangling) → подхватываем намерение: это попытка категоризации, направляем в новый под-MOC

Классификация соседа:

Тип соседа	Действие
Атомарка / концепт (#thought)	стандартная перепривязка
MOC / карта (#moc, MapOfContent)	стандартная перепривязка; добавляем как down в новый под-MOC
Заметка-упоминание (#person, ссылка на компанию, инструмент)	не считается категоризуемым соседом — остаётся в hub как контекстная ссылка, не уходит в под-MOC
Заметка из 02. Сферы/05. Медийность/ (Telegram, контент)	свой жизненный цикл (status, publication_date, link); up не трогаем
Заметка с up на существующий альтернативный под-MOC	уже категоризована — оставляем; добавляем альтернативу в other нового под-MOC как родственную карту

Не читай полное тело — для категоризации хватает тезиса и frontmatter. Если тезис непонятен — посмотри первый заголовок.

4. Категоризация

Главный принцип: под-MOC — это точки приземления для будущих in-links. Категория должна быть достаточно «семантически устойчивой», чтобы на неё можно было осмысленно ссылаться из новой заметки.

Если hub уже структурирован подзаголовками (##-секции) — используй их как готовые категории. Не выдумывай оси, если автор карты уже выполнил эту работу. Достаточно вынести подсекции в под-MOC, даже если они по 3–4 заметки. Это бережнее и сохраняет ментальную модель автора.

Если подзаголовков нет — подбери ось из таблицы, которая лучше ложится на материал:

Ось	Когда применять	Пример категорий
По домену знаний	Когда hub намешал несколько областей	SRE, Экономика, Психология
По уровню абстракции	Когда hub — большая дисциплина	Принципы, Инструменты, Опыт, Источники
По типу артефакта	Когда соседи разной природы	Концепты, Литературные, Синтезы, Проекты
По уровню зрелости	Когда есть confidence	Подтверждённые, Спорные, В работе
По существующим тегам	Когда в frontmatter уже есть устойчивая разметка	по tags.md

Размер категории:

• Минимум 2 заметки, если категория уже намечена подзаголовком или существующей структурой — она «семантически устойчива», под-MOC оправдан.
• Минимум 3 заметки, если категория выдумывается с нуля — иначе шум.
• Если категория > 20 — она сама клубок, дроби её внутри (2-уровневая структура Hub → группа → под-MOC).

Имя категории — claim-based, по file-naming.md. Для семейства под-MOC от одного родителя — формат <Родитель> – <Категория>: DevOps – Управление инфраструктурой, DevOps – Деплой и релиз. Это сохраняет родство в графе.

Раздел «Прочее» в hub — куда идут одиночки, не попавшие в категории. Не дроби под них под-MOC.

Стоп-сигнал: если категорий не получается ни по одной оси — материал монолитный. Распутывать нечего. Скажи об этом и предложи obsidian-note-critic.

5. План разгрузки → подтверждение

Разгрузка идёт в две итерации — каркасная и in-links. Это важно: реальное падение in-degree приходит только во второй. Не обещай пользователю чудес после первой.

Итерация 1 (каркас, безопасная):

• Создать под-MOC
• Перепривязать up у out-соседей (поток A)
• Перепривязать up у up-children (поток B) — может быть кратно больше, чем A
• Минимально обновить тело hub (pointers, frontmatter down)

Обе перепривязки up объединяются — это правки frontmatter, операция симметричная и безопасная. Делим на подпачки только если up-children > 50: батчи по 10–20 за раз, по категориям/папкам.

Итерация 2 (in-links в телах, опциональная):

• Перенаправить in-links в телах ресурсных заметок (поток C)
• Это тяжелее: нужен контекст ссылки, чтобы определить категорию
• Реально применимо только к заметкам, где [[Hub]] — центральная тема обсуждения. У большинства упоминаний [[Hub]] — это родственная контекстная ссылка, её перепривязка ломает смысл текста
• Может оказаться, что эта итерация почти не нужна — если после итерации 1 in-degree уже упал на ожидаемую величину

Формат плана:

🧶 Hub: [[DevOps]]
   in: 222   out: 22   тип: MOC
   dangling out-links: 4 (Deployment Pipeline, Change Management, GitOps, ChatOps)
   соседи с альтернативным up: 2 (Blue-Green, Canary — привязаны к [[Стратегии развертывания...]])

═══ Итерация 1 (каркас) ═══

Создать под-MOC (в 03. Ресурсы/07. Карты/):
  1. [[DevOps – Основы]]                       → 3 out-link
  2. [[DevOps – Управление инфраструктурой]]   → 4
  3. [[DevOps – Деплой и релиз]]               → 1 (Blue-Green/Canary остаются в альт. карте)
  4. [[DevOps – Процессы и подходы]]           → 1 (GitOps/ChatOps dangling)

Прочее (одиночки, остаются в hub): DORA Metrics, Культура, ИБ, DevSecOps

Перепривязать `up` у out-соседей: ~8 заметок (после фильтрации danling/альтернативных/упоминаний)

Минимально обновить тело [[DevOps]]:
   — Pointer-строка `→ Подкарта: [[под-MOC]]` в каждый соответствующий ##-подзаголовок
   — frontmatter `down`: добавить ссылки на новые под-MOC
   — Не переписывать тело целиком: структура уже есть

Ожидаемый эффект: in-degree оригинала упадёт незначительно (~5–10),
                  потому что в телах ссылки остаются. Каркас стоит.

═══ Итерация 2 (in-links, отдельный прогон) ═══

Перенаправить in-links в телах ресурсных заметок:
   Всего ресурсных in-links: ~160
       — 03. Ресурсы/04. Заметки/        131  ← тяжёлая, дробить на подпачки
       — 03. Ресурсы/07. Карты/           17
       — 03. Ресурсы/02. Статьи/           5
       — 03. Ресурсы/01. Книги/            3
       — 03. Ресурсы/03. Литературные/    3
       — 03. Ресурсы/05. Видео/            1
   Не трогаем (~60): 01. Проекты/, 02. Сферы/, 05. Дневник/, 04. Архив/, 00. Входящие/

Ожидаемый эффект: in-degree оригинала упадёт на 50–70% (из ресурсной массы).

Дождись подтверждения на каждую итерацию отдельно. После итерации 1 покажи отчёт и спроси, идти ли в итерацию 2.

Исключения из подтверждения — те же, что в workflows.md: «делай сразу», «без подтверждения».

6. Выполнение

Порядок шагов важен, чтобы не словить broken-links на промежуточных этапах:

6.1. Создать под-MOC

В 03. Ресурсы/07. Карты/ по Шаблон карты.md:

---
aliases: []
tags:
  - moc
up:
  - "[[Оригинальный hub]]"
down: []   # будет заполнен ссылками на категорийные заметки
links: []
other: []
---

В теле — короткое описание категории (1–2 предложения) и список ссылок:

## Заметки

- [[Заметка 1]] — что в ней
- [[Заметка 2]] — что в ней

## Связанные карты

- [[Сосед-MOC]]
- [[Альтернативный под-MOC]] — родственная карта, если по теме уже есть параллельная категоризация

Если в шаге 3 у какого-то соседа был обнаружен существующий альтернативный под-MOC (например, Blue-Green уже привязан к Стратегии развертывания приложений в Kubernetes), добавь этот под-MOC сразу в other нашего под-MOC и в раздел «Связанные карты». Это уважение к предыдущей категоризации автора — мы не дублируем, а ссылаемся.

6.2. Перепривязать up у out-соседей

Для каждого out-соседа определи ветку по результату шага 3 и действуй соответственно:

Ветка A — up ссылается на сам hub ([[DevOps]]):

Заменить на [[Под-MOC]]. Если в up несколько родителей — замени только ссылку на hub, остальные оставь.

Ветка B — up пустой:

Добавь [[Под-MOC]] (не hub) — мы сразу проставляем правильную категоризацию.

Ветка C — up содержит dangling wikilink (например, [[DevOps – Практики]] который не существует как файл):

Это намерение автора категоризовать — подхватываем его. Заменяем dangling на актуальный под-MOC ([[DevOps – Процессы и подходы]] в нашем примере). Это важно: автор уже пытался создать категорию, мы её закрываем.

Ветка D — up содержит существующий альтернативный под-MOC (например, [[Стратегии развертывания приложений в Kubernetes]], файл есть):

НЕ трогаем. Заметка уже категоризована, у неё есть «свой родитель». В план разгрузки эта заметка идёт как «остаётся на альт. карте», а в нашем новом под-MOC указываем родственную карту через other и «Связанные карты».

Ветка E — соседи-упоминания (#person, ссылка на компанию, инструмент):

Не считаются категоризуемыми. up не трогаем, заметка остаётся в hub как контекстная ссылка.

Ветка F — Telegram/контентные заметки (02. Сферы/05. Медийность/Telegram/):

up не трогаем — у заметок свой жизненный цикл и frontmatter (status, publication_date, link).

Ветка G — у соседа в up уже есть более точный родитель, а [[Hub]] лишний:

Когда up: [[Другой MOC]], [[Hub]], и другой MOC семантически точнее для этой заметки (например, у Incident Management есть up: [[Site Reliability Engineering]], [[DevOps]] — она про SRE/ITSM, не подкатегория DevOps), правильное действие — удалить ссылку на Hub из up, а не перепривязывать.

Признак ветки G: ни одна из наших под-MOC не подходит семантически, и при этом у заметки уже есть другой родитель, который точнее. Это сигнал, что [[Hub]] в up была ошибочной двусвязностью — навигационной, а не категорийной.

Не путать с веткой D: в D заметка уже категоризована альтернативным под-MOC (одного семейства с hub), там альт. родитель — это другая категоризация той же темы. В G — заметка про другую тему, и hub был просто лишним.

Бонус-исправление по пути: если в теле заметки обнаружились dangling wikilinks из старой попытки категоризации hub (например, [[DevOps – Практики]] — несуществующий файл), их стоит заменить на актуальный wikilink ([[DevOps|практиками DevOps]] через pipe-алиас или на подходящий под-MOC). Это попутная гигиена графа, не основная работа скилла.

Общие тонкости:

• Сохраняй формат списка/строки (YAML), как в исходной заметке.
• Литературные источники остаются в sources без изменений (политика «up + sources синхронны» из note-types-frontmatter.md — синхронизуй обе стороны, если меняешь).

6.3. Перенаправить in-links (главный шаг)

Это основное действие скилла. Получаем список всех заметок, которые ссылаются на оригинал:

rg -l -F "[[Имя hub]]" --type md . > /tmp/in-links.txt

Фильтр папок (важно):

В перепривязку попадают только заметки информационной/ресурсной природы:

• ✅ 03. Ресурсы/01. Книги/
• ✅ 03. Ресурсы/02. Статьи/
• ✅ 03. Ресурсы/03. Литературные заметки/
• ✅ 03. Ресурсы/04. Заметки/ (концепты, мысли)
• ✅ 03. Ресурсы/05. Видео/
• ✅ 03. Ресурсы/07. Карты/ (другие MOC)

Не трогаем — ссылки сделаны намеренно как «общая точка входа», их перепривязка ломает исторический контекст:

• ❌ 01. Проекты/ — проектные заметки ссылаются на общий MOC сознательно
• ❌ 02. Сферы/03. Работа/ — встречи, 1:1 — контекстные ссылки
• ❌ 02. Сферы/06. Конференции/ — конспекты докладов как точка времени
• ❌ 05. Дневник/ — журнал, исторический контекст
• ❌ 04. Архив/ — заархивированное
• ❌ 00. Входящие/ — необработанные, оставляем для obsidian-refactor-inbox

Для каждой подходящей заметки:

1. Прочти контекст ссылки (одну-две строки вокруг неё)
2. Определи, к какой категории относится материал заметки
3. Если определимо — замени [[Оригинал]] на [[Под-MOC]] в теле заметки
4. Если неопределимо или общий контекст — оставь [[Оригинал]] как есть. Это правильное поведение: общий MOC и есть «общая точка входа».
5. Если в одной заметке несколько ссылок на оригинал — каждую обрабатываем отдельно, могут уйти в разные под-MOC.

Не трогай ссылки в:

• > [!quote] и > [!note] callout-блоках — это исторические цитаты
• В frontmatter sources — это летопись источников
• В callout-блоках с явной разметкой «Ревью», «История изменений», «Контекст»

Спорные случаи (категория неясна, заметка пограничная) — оставь оригинальную ссылку и выпиши в раздел отчёта «Под вопросом».

6.4. Минимально обновить тело оригинального hub

Не переписывай тело hub целиком. Структура подзаголовками — это ментальная модель автора, она ценна. Достаточно вписать ссылки на под-MOC.

Если у hub есть подзаголовки (## Категория):

Для каждого подзаголовка, который мы вынесли в под-MOC, первой строкой после заголовка добавь компактный pointer:

## Управление инфраструктурой

→ Подкарта: [[DevOps – Управление инфраструктурой]]

- [[Infrastructure as Code (IaC)]]
- [[Infrastructure from Code (IfC)]]
    - [[Сравнение и отличия между IaC и IfC]]
- [[Configuration Management]]

Существующие out-links под заголовком не трогай — они остаются как удобная навигация. Под-MOC и hub отображают одну и ту же информацию с разных уровней детализации.

Если у hub нет подзаголовков и тело — плоский список:

Сгруппируй ссылки по категориям, добавь подзаголовки. Это уже более ощутимая перестройка тела, но сохраняй порядок и формулировки где возможно.

В frontmatter оригинала:

• В down добавить wikilinks на новые под-MOC (рядом с уже существующими down)
• Остальное (up, aliases, links, other, tags, Bases/Dataview) — не трогать

6.5. Заполнить down у под-MOC

В каждом под-MOC в down — список всех заметок, у которых теперь up: [[Под-MOC]]. Это можно сделать вручную (как в плане) — нет нужды заново сканировать.

7. Отчёт

После итерации 1 (каркас) — обязательное предупреждение:

✅ Каркас разгрузки [[DevOps]] стоит

   in (точные [[DevOps]]):  192 → 191  (−1)
   in (через pipe):          30 →  30   (=)

⚠️ Важно: in-degree оригинала упал слабо — это ожидаемо.
   Мы перепривязали только `up` в frontmatter (8 соседей).
   В телах ресурсных заметок ссылки на [[DevOps]] остались.
   Реальный эффект придёт после итерации 2.

Создано под-MOC: 4
  [[DevOps – Основы]]                       in=3
  [[DevOps – Управление инфраструктурой]]   in=8
  [[DevOps – Деплой и релиз]]               in=5
  [[DevOps – Процессы и подходы]]           in=5

Перепривязан `up` у out-соседей: 8 (из 22 после фильтрации)

Под вопросом / отдельная работа:
  • Dangling out-links у hub: [[Deployment Pipeline]], [[Change Management]],
    [[GitOps]], [[ChatOps]] — заметок нет, заглушки в hub остались.
  • Альтернативная категоризация: [[Blue-Green]], [[Canary Deploy]]
    остались на [[Стратегии развертывания приложений в Kubernetes]];
    эта карта добавлена в `other` нового под-MOC «Деплой и релиз».

Идём в итерацию 2 (перенаправление ~160 in-links в телах)?

После итерации 2 (in-links):

✅ [[DevOps]] разгружен

   in:  191 → 60–80   (реальное падение)

Перенаправлено in-links по подпачкам:
   03. Ресурсы/04. Заметки/    105 из 131
   03. Ресурсы/07. Карты/       13 из 17
   03. Ресурсы/02. Статьи/       3 из 5
   03. Ресурсы/01. Книги/        2 из 3
   03. Ресурсы/03. Лит.заметки/  2 из 3
   03. Ресурсы/05. Видео/        1 из 1

Сохранено as-is: ~60 (вне ресурсной области — намеренные общие ссылки) +
                  ~10 ресурсных, где категория неясна (см. «Под вопросом»)

Под вопросом (10):
  • [[Заметка X]] — между «Деплой» и «Процессы»; оставил [[DevOps]].
  ...

Если по ходу выявилось что-то новое (соседняя заметка тоже — hub, противоречие между двумя соседями, дубликаты внутри категории) — упомяни в отчёте, но не лезь туда в той же итерации.

---

Особые случаи

Заметка не MOC, но обросла связями

Атомарка/концепт стихийно стал хабом (типа Kubernetes с 30 связями). Два варианта:

1. Превратить в MOC — если заметка по сути уже карта. Поменять #thought → #moc, обновить frontmatter по Шаблон карты.md, переместить в 03. Ресурсы/07. Карты/. Backlinks при этом не ломаются — Obsidian обновит по переименованию.
2. Оставить концепт — если содержание самостоятельное и заслуживает быть концептом. Разгружаем связи (категоризуем соседей в под-MOC), но саму заметку не переделываем.

Спроси пользователя в момент выбора hub.

Категория не выделяется

Если ни одна ось не даёт ≥3 заметки на категорию — материал не клубок. Скажи прямо:

Связей много, но категорийной структуры в них нет — соседи в одном смысловом поле. Это не клубок, а действительно центр темы. Распутывать нечего.

Предложи obsidian-note-critic для углубления или obsidian-split-note, если заметка большая.

in-links на hub из проектных заметок

Не перепривязывай ссылки из 01. Проекты/, 02. Сферы/, 05. Дневник/, 04. Архив/, 00. Входящие/. Эти ссылки сделаны как «общая точка входа», их перепривязка ломает исторический контекст. Перепривязываем только in-links из ресурсных заметок (03. Ресурсы/).

Hub уже частично структурирован

Если у hub есть подсекции в теле (## Принципы, ## Инструменты), это готовая категоризация автора — используй её, не выдумывай с нуля. Достаточно вынести каждый подзаголовок в отдельный под-MOC и добавить компактный pointer в начало секции.

Out-клубок (низкий in, высокий out)

В этой базе встречается редко (out обычно растёт медленнее), но возможен — например, свежая большая карта, которую только что собрали. Сценарий:

• Перепривязка in-links не нужна (их мало)
• Главное действие — переписать тело hub в оглавление по под-MOC
• Под-MOC создаются для красоты графа, а не для перенаправления потока ссылок

Если попал на out-клубок — спроси у пользователя, какой эффект он хочет (навигация vs нагрузка graph view). Действие выбирается по этому ответу.

Concept-hub (атомарка с большим in)

Атомарка/концепт (типа Kubernetes) обросла in-links. Два варианта:

1. Превратить в MOC — если содержание уже больше похоже на карту. Сменить #thought → #moc, переместить в 03. Ресурсы/07. Карты/. Backlinks Obsidian обновит при переименовании.
2. Оставить концептом + создать MOC рядом — если содержание самостоятельное и ценно как концепт. Создаётся Kubernetes – MOC.md, и in-links перенаправляются на него; концепт остаётся узким объектом «определение/идея».

Спроси пользователя в момент выбора hub.

Двусторонние ссылки (заметка в up и down оригинала)

Симптом запутанности. Покажи их явно: «в up и в down одновременно: N заметок». Спроси, какое направление оставить. По умолчанию: более общая остаётся в up, более частная — в down. Двусторонней ссылки быть не должно.

---

Что НЕ делать

• Не удалять оригинал — он остаётся как корневой MOC, верхний уровень оглавления и общая точка входа.
• Не переписывать тело hub целиком, если оно уже структурировано подзаголовками — добавляй pointer на под-MOC, не ломай ментальную модель автора.
• Не перепривязывать ссылки за пределами 03. Ресурсы/ — проекты, дневник, конференции, архив, инбокс не трогаем; их ссылки на общий MOC намеренны.
• Не игнорировать существующий up у соседа. Если он указывает на dangling — подхвати намерение автора. Если на существующий альтернативный под-MOC — уважай и не трогай, добавь его в other нового под-MOC как родственную карту.
• Не считать упоминания людей и компаний (#person, [[Какая-то Компания]]) категоризуемыми соседями — они остаются в hub как контекстные ссылки.
• Не трогать Telegram/контентные заметки в 02. Сферы/05. Медийность/ — у них свой жизненный цикл (status, publication_date, link).
• Не пытаться перепривязать ссылку на dangling out-link у hub — заметки нет, заглушка остаётся в hub до ручного создания через obsidian-ingest.
• Не трогать ссылки внутри > [!quote], > [!note], > [!warning] и других callout-блоков — это исторический контекст или цитаты.
• Не трогать sources при перепривязке up — это летопись источников, она синхронна с up по политике из note-types-frontmatter.md.
• Не двигать соседние заметки между папками PARA — мы перевязываем связи, а не миграцию структуры.
• Не делать рекурсивную разгрузку — один hub за прогон.
• Не объединять каркас и in-links в одну итерацию — после каркаса дай пользователю увидеть результат и решить, идти ли в тяжёлую часть.
• Не очищать links и other в соседях — только up подлежит замене.
• Не выдумывать категории, когда у hub есть готовые подзаголовки — используй то, что есть.
• Не обещать большое падение in-degree после итерации 1 — это каркас, реальный эффект приходит во второй итерации.

---

Чек-лист перед завершением

Под-MOC:

• Созданы в 03. Ресурсы/07. Карты/ с #moc и frontmatter по Шаблон карты.md
• up указывает на оригинальный hub
• down заполнен (вручную списком или Dataview)
• Имена без запрещённых символов (file-naming.md); формат <Родитель> – <Категория>

Out-соседи (заметки, на которые ссылается hub):

• up перепривязан с оригинала на соответствующий под-MOC (если применимо по структурному тегу)
• Литературные источники синхронны в up и sources (политика Б из note-types-frontmatter.md)

In-links (главное):

• Прошлись по ресурсным in-links (только 03. Ресурсы/)
• Где категория ясна — заменили [[hub]] на [[под-MOC]]
• Где категория неясна — оставили как есть, выписали в «Под вопросом»
• Не тронули 01. Проекты/, 02. Сферы/, 05. Дневник/, 04. Архив/, 00. Входящие/
• Не тронули callout-блоки и sources

Оригинальный hub:

• Тело — минимально обновлено (pointer в начало каждого подзаголовка), не переписано целиком
• down дополнен новыми под-MOC
• Bases/Dataview, aliases, up, links, other, tags — без изменений