| 1 | # ADR 007: KB Project Constitution |
| 2 | |
| 3 | **Статус:** Proposed |
| 4 | **Дата:** 2026-05-05 |
| 5 | **Supersedes:** — |
| 6 | **Extended by:** — |
| 7 | **Связь:** [001](001-kb-public-publishing-pipeline.md), [002](002-integrity-post-and-epistemic-baseline.md), [003](003-multi-project-scope-and-project-cards.md), [004](004-router-supplement-and-l1-pool.md), [005](005-kb-base-cide-bundle.md), [006](006-zettelkasten-overlay-for-kb.md) |
| 8 | |
| 9 | --- |
| 10 | |
| 11 | ## Контекст |
| 12 | |
| 13 | KB выросла в операционную систему знаний с несколькими контурами (public/internal/base/extended), но базовые правила проекта были распределены по разным документам и не собраны в единую "конституцию". |
| 14 | |
| 15 | Нужен один документ, который фиксирует неизменяемые принципы проекта, чтобы новые решения и изменения состава KB проверялись against единый конституционный контракт. |
| 16 | |
| 17 | --- |
| 18 | |
| 19 | ## Решение |
| 20 | |
| 21 | Зафиксировать проектную конституцию KB как набор обязательных принципов: |
| 22 | |
| 23 | 1. **Single Source of Truth** |
| 24 | - Канон знаний живёт в `knowledge/*.md`; производные бандлы формируются скриптами, не вручную. |
| 25 | |
| 26 | 2. **Layered Delivery** |
| 27 | - Есть обязательный слой (`KB-Base`) и опциональные расширения (`KB-Extended`). |
| 28 | - Поставка должна быть воспроизводимой и проверяемой. |
| 29 | |
| 30 | 3. **Integrity and Epistemic Baseline** |
| 31 | - Integrity POST и эпистемический baseline применяются независимо от домена. |
| 32 | - При конфликте интерпретаций приоритет у baseline-контракта. |
| 33 | |
| 34 | 4. **Privacy by Architecture** |
| 35 | - Личный слой (`knowledge/personal/**`) отделён архитектурно и не должен утекать в публичные сборки. |
| 36 | |
| 37 | 5. **Router-First Retrieval** |
| 38 | - Доступ к знанию строится от краткого роутера к детализации, а не от чтения тяжёлых документов "вслепую". |
| 39 | |
| 40 | 6. **Traceable Evolution** |
| 41 | - Ключевые архитектурные развилки фиксируются ADR-ами. |
| 42 | - ADR-цепочка должна оставаться хронологичной и читаемой. |
| 43 | |
| 44 | 7. **Format Contract** |
| 45 | - Контент знаний: Markdown (`md`). |
| 46 | - Формат конфигурации потребителя определяется самим потребителем (например, в CIDE это TOML-first), но это не меняет канон KB. |
| 47 | |
| 48 | --- |
| 49 | |
| 50 | ## Последствия |
| 51 | |
| 52 | **Плюсы** |
| 53 | |
| 54 | - Решения по KB можно оценивать against явный конституционный контракт. |
| 55 | - Снижается риск дрейфа стандартов при росте объёма и числа доменов. |
| 56 | - Проще подключать потребителей (например, CIDE) без дублирования правил. |
| 57 | |
| 58 | **Минусы** |
| 59 | |
| 60 | - Появляется дополнительный уровень governance (нужно поддерживать конституцию актуальной). |
| 61 | - Любые "быстрые исключения" должны обосновываться и фиксироваться явно. |
| 62 | |
| 63 | --- |
| 64 | |
| 65 | ## Governance rule |
| 66 | |
| 67 | - Любой ADR, затрагивающий слои поставки, baseline, роутинг, приватность, должен явно указать совместимость с этой конституцией. |
| 68 | - Если ADR предлагает отступление, он должен содержать явное обоснование и границы отступления. |
| 69 | |
| 70 | --- |
| 71 | |
| 72 | ## План внедрения |
| 73 | |
| 74 | 1. Считать этот ADR входной точкой для ревью новых архитектурных изменений KB. |
| 75 | 2. При необходимости добавить краткие ссылки на конституцию в ключевые индексные документы KB. |
| 76 | 3. Поддерживать согласованность с `kb-base-cide.include` и скриптами сборки бандлов. |
| 77 | |
| 78 | |