| 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.
Скилл:
- Находит/принимает hub и считает in/out
- Опирается на уже существующую структуру hub (подзаголовки, явные категории) как на готовые точки приземления — не выдумывает новые категории, когда их не просили
- Создаёт под-MOC под каждую категорию
- Главное действие: проходит по входящим ссылкам из ресурсных заметок и переключает их с общего MOC на подходящий под-MOC
- Оригинальный 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. Карты/ (по умолчанию) или другой папке по запросу:
for f in "03. Ресурсы/07. Карты/"*.md; do
out=$(rg -o '\[\[[^\]]+\]\]' "$f" | wc -l)
echo "$out $f"
done | sort -rn | head -10
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 (тяжёлая, опциональная) |
Подсчёт:
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)
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
s = re.search(r'^up:\s*(.+)$', fm, re.M)
if s and '[[Hub]]' in s.group(1):
res.append(p)
print(len(res))
PY
rg -l -F "[[Hub]]" --type md . | wc -l
rg -l -F "[[Hub]|" --type md . | wc -l
Зафиксируй:
- 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 пустой → добавляем под-MOCup содержит [[Hub]] → заменяем на под-MOCup содержит [[Какой-то – Альтернативный – под-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
Для каждой подходящей заметки:
- Прочти контекст ссылки (одну-две строки вокруг неё)
- Определи, к какой категории относится материал заметки
- Если определимо — замени
[[Оригинал]] на [[Под-MOC]] в теле заметки
- Если неопределимо или общий контекст — оставь
[[Оригинал]] как есть. Это правильное поведение: общий MOC и есть «общая точка входа».
- Если в одной заметке несколько ссылок на оригинал — каждую обрабатываем отдельно, могут уйти в разные под-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 связями). Два варианта:
- Превратить в MOC — если заметка по сути уже карта. Поменять
#thought → #moc, обновить frontmatter по Шаблон карты.md, переместить в 03. Ресурсы/07. Карты/. Backlinks при этом не ломаются — Obsidian обновит по переименованию.
- Оставить концепт — если содержание самостоятельное и заслуживает быть концептом. Разгружаем связи (категоризуем соседей в под-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. Два варианта:
- Превратить в MOC — если содержание уже больше похоже на карту. Сменить
#thought → #moc, переместить в 03. Ресурсы/07. Карты/. Backlinks Obsidian обновит при переименовании.
- Оставить концептом + создать 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:
Out-соседи (заметки, на которые ссылается hub):
In-links (главное):
Оригинальный hub:
