| 1 | # ADR 006: Zettelkasten Overlay for KB |
| 2 | |
| 3 | **Статус:** Proposed |
| 4 | **Дата:** 2026-05-05 |
| 5 | **Supersedes:** — |
| 6 | **Extended by:** — |
| 7 | |
| 8 | --- |
| 9 | |
| 10 | ## Контекст |
| 11 | |
| 12 | Текущий KB хорошо покрывает операционные сценарии через `status-*`, `playbook-*`, `kb-*` и роутерные индексы. |
| 13 | При этом междоменные смысловые связи (поддержка/контраст/ограничение гипотез) часто остаются неявными и теряются между документами. |
| 14 | |
| 15 | Нужен слой, который: |
| 16 | |
| 17 | - не ломает текущую структуру; |
| 18 | - позволяет атомарно фиксировать идеи и связи между ними; |
| 19 | - не превращает KB в ручной хаос ссылок. |
| 20 | |
| 21 | --- |
| 22 | |
| 23 | ## Решение |
| 24 | |
| 25 | Добавить поверх текущего канона **Zettelkasten overlay** как отдельный, опциональный слой: |
| 26 | |
| 27 | - каталог: `knowledge/zettel/`; |
| 28 | - атомарная заметка = один тезис; |
| 29 | - обязательные поля заметки: |
| 30 | - `id` |
| 31 | - `thesis` |
| 32 | - `evidence_links` |
| 33 | - `out_links` |
| 34 | - `tags` |
| 35 | - типы связей минимум: |
| 36 | - `supports` |
| 37 | - `contrasts` |
| 38 | |
| 39 | Текущие `status/playbook/kb` остаются первичным operational-контуром. Zettel-слой используется для междоменного смыслового связывания и эволюции reasoning-моделей. |
| 40 | |
| 41 | --- |
| 42 | |
| 43 | ## Не-цели |
| 44 | |
| 45 | - Не заменять существующие индексы и playbook. |
| 46 | - Не требовать zettel-оформления для каждого документа KB. |
| 47 | - Не вводить ручную обязательную линковку "всего со всем". |
| 48 | |
| 49 | --- |
| 50 | |
| 51 | ## Последствия |
| 52 | |
| 53 | **Плюсы** |
| 54 | |
| 55 | - Улучшается связность идей между доменами. |
| 56 | - Проще растить reasoning substrate (гипотеза -> проверка -> инвариант). |
| 57 | - Снижается риск "мертвых" знаний без входящих/исходящих связей. |
| 58 | |
| 59 | **Минусы** |
| 60 | |
| 61 | - Появляется риск шумового роста заметок. |
| 62 | - Нужен governance по атомарности и дублированию. |
| 63 | - Нужны инструменты авто-индексации для устойчивой работы. |
| 64 | |
| 65 | --- |
| 66 | |
| 67 | ## План внедрения (pilot) |
| 68 | |
| 69 | 1. Запустить пилот на 20-30 zettel-заметок в `knowledge/zettel/`. |
| 70 | 2. Добавить легкий авто-индекс (список заметок + типы связей). |
| 71 | 3. Оценить полезность по сценариям: |
| 72 | - быстрее ли находятся междоменные аргументы; |
| 73 | - уменьшается ли дублирование рассуждений. |
| 74 | 4. Если шум > пользы — остановить слой как optional experiment без влияния на core KB. |
| 75 | |
| 76 | --- |
| 77 | |
| 78 | ## Открытые вопросы |
| 79 | |
| 80 | - Нужен ли отдельный формат front-matter или достаточно markdown-полей по шаблону? |
| 81 | - Какие метрики считать "успехом" пилота (время поиска, повторное использование, качество ответов)? |
| 82 | - В какой момент links становятся обязательными для заметки? |
| 83 | |
| 84 | |