obsidian-untangle-knot · git:20260809.e38cc46 · 2026-08-09 · sha256 b7edd9531ab5d72a
obsidian-untangle-knot git:20260809.e38cc46A
Immutable. This exact content never changes and is served at /api/v1/blob/b7edd9531ab5d72a.
---
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]]»). Найди файл по имени:
```bash
fd -t f "DevOps.md" .
```
Если имён несколько — спроси, какой именно.
**Discovery** — пользователь хочет найти кандидатов («найди мои hub-заметки», «где у меня перегруз»). Прогон по `03. Ресурсы/07. Карты/` (по умолчанию) или другой папке по запросу:
```bash
# Подсчёт 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
```
```bash
# Подсчёт 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 (тяжёлая, опциональная) |
**Подсчёт:**
```bash
# Поток 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`:
```yaml
---
aliases: []
tags:
- moc
up:
- "[[Оригинальный hub]]"
down: [] # будет заполнен ссылками на категорийные заметки
links: []
other: []
---
```
В теле — короткое описание категории (1–2 предложения) и список ссылок:
```markdown
## Заметки
- [[Заметка 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 (главный шаг)
Это **основное** действие скилла. Получаем список всех заметок, которые ссылаются на оригинал:
```bash
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:
```markdown
## Управление инфраструктурой
→ Подкарта: [[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` — без изменений