docs: add MECE governance principle and audit

README.md

@@ -103,6 +103,7 @@ service setup-команды проекта; он намеренно не пер
 
 ### Методические источники
 
+- [MECE principle](https://en.wikipedia.org/wiki/MECE_principle) — определение принципа Mutually Exclusive, Collectively Exhaustive: непересекающиеся категории, которые вместе покрывают заявленную область;
 - Philippe Kruchten, [*Architectural Blueprints — The “4+1” View Model of Software Architecture*](https://arxiv.org/abs/2006.04975) — первичный источник stakeholder-oriented проверки Logical, Process, Development и Physical views через driving scenarios; [краткий обзор](https://en.wikipedia.org/wiki/4%2B1_architectural_view_model);
 - Nenad Medvidovic, Richard N. Taylor, [*A Classification and Comparison Framework for Software Architecture Description Languages*](https://ics.uci.edu/~taylor/documents/2000-ADLs-TSE.pdf) — источник архитектурной модели components, connectors и configurations.
 

template/memory-bank/dna/README.md

@@ -23,7 +23,7 @@ source set `governed_artifact`.
 [`governance.yaml`](../flows/priming/governance.yaml) и выполни source set
 `memory_bank_governance`.
 
-- [Principles](principles.md) — фундаментальные принципы проекта: SSoT, атомарность, progressive disclosure. Читать первым.
+- [Principles](principles.md) — фундаментальные принципы проекта: SSoT, MECE для применимых классификаций, атомарность и progressive disclosure. Читать первым.
 - [Document Governance](governance.md) — SSoT implementation, dependency tree. Отвечает на вопрос: кто владеет фактом.
 - [Frontmatter Schema](frontmatter.md) — schema полей frontmatter.
 - [Document Lifecycle](lifecycle.md) — maintenance rules, sync checklist.

template/memory-bank/dna/principles.md

@@ -7,11 +7,12 @@ status: active
 # Principles
 
 1. **SSoT.** Каждый факт имеет ровно одного canonical owner. Дубли = дефект.
-2. **Атомарность.** Один файл = одна тема. Разрастается — разбивай.
-3. **Компактность.** Документ должен оставаться читаемым. Разрастается — разбивай.
-4. **Progressive disclosure.** Сначала обзор, затем ссылки вглубь. Сверху вниз.
-5. **WHY / WHAT / HOW.** `prd/`, `use-cases/` и feature `brief.md` = что; `adr/` и feature `design.md` = почему выбран подход; `implementation-plan.md` и код = как выполняем.
-6. **Code vs Docs.** Код владеет реализацией. Документация владеет intent, rationale и contracts.
-7. **Index-first.** Каждый документ в индексе. Orphan файл = дефект.
-8. **Аннотированные ссылки.** Ссылка объясняет: что по ней и зачем читать.
-9. Каждое архитектурное решение — отдельный ADR в выделенном разделе.
+2. **Структурная полнота и непересечение (MECE — Mutually Exclusive, Collectively Exhaustive).** При декомпозиции, классификации и построении индексов элементы одного уровня должны не пересекаться и вместе покрывать заявленный scope. Если пересечение или неполнота намеренны, явно зафиксируй precedence, fallback или ограничение scope. Не применяй MECE механически к открытым спискам, ортогональным представлениям или графам зависимостей.
+3. **Атомарность.** Один файл = одна тема. Разрастается — разбивай.
+4. **Компактность.** Документ должен оставаться читаемым. Разрастается — разбивай.
+5. **Progressive disclosure.** Сначала обзор, затем ссылки вглубь. Сверху вниз.
+6. **WHY / WHAT / HOW.** `prd/`, `use-cases/` и feature `brief.md` = что; `adr/` и feature `design.md` = почему выбран подход; `implementation-plan.md` и код = как выполняем.
+7. **Code vs Docs.** Код владеет реализацией. Документация владеет intent, rationale и contracts.
+8. **Index-first.** Каждый документ в индексе. Orphan файл = дефект.
+9. **Аннотированные ссылки.** Ссылка объясняет: что по ней и зачем читать.
+10. Каждое архитектурное решение — отдельный ADR в выделенном разделе.