Skip to content

docs: add MECE classification principle #111

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
dapi wants to merge 2 commits into
base: main
Choose a base branch
from
Draft

docs: add MECE classification principle #111

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
b9c0763
docs: add MECE classification principle
dapi Aug 6, 2026
7392ed0
docs: list MADR as methodology source
dapi Aug 6, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -102,6 +102,11 @@ service setup-команды проекта; он намеренно не пер

### Методические источники

- [MECE principle](https://en.wikipedia.org/wiki/MECE_principle) — источник
правила для непересекающихся и совместно исчерпывающих закрытых
классификаций;
- [Markdown Architectural Decision Records (MADR)](https://adr.github.io/madr/) —
источник структуры и authoring guidance для локального ADR template;
- 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.

Expand Down
17 changes: 9 additions & 8 deletions template/memory-bank/dna/principles.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 для закрытых классификаций.** Перед созданием sibling-категорий объяви классифицируемую область. Каждый объект этой области должен иметь ровно одну основную категорию. Пересечения разрешай через canonical ownership или явный precedence, а непокрытые случаи — через explicit fallback или Human Routing. Cross-references допустимы, duplicate ownership запрещён. Не применяй MECE к открытым спискам, ортогональным осям или dependency graph с несколькими обоснованными upstream.
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 в выделенном разделе.
Loading