refactor(semantics): migrate TIER system to adaptive COMPLEXITY 1-5 scale

- Replaced rigid TIERs with continuous COMPLEXITY 1-5 scale in semantics.md
- Updated generate_semantic_map.py to parse and score based on Complexity
- Added backward compatibility mapping for legacy TIERs
- Migrated all .ai/shots examples to use @COMPLEXITY and updated relation syntax
- Added trivial_utility.py shot to demonstrate implicit Complexity 1 token savings

.ai/standards/semantics.md

@@ -30,7 +30,7 @@
 
 ## III. ТОПОЛОГИЯ ФАЙЛА (СТРОГИЙ ПОРЯДОК)
 1. **HEADER (Заголовок):**[DEF:filename:Module]
-   @TIER: [CRITICAL | STANDARD | TRIVIAL]
+   @COMPLEXITY: [1|2|3|4|5] *(алиас: `@C:`; legacy `@TIER` допустим только для обратной совместимости)*
    @SEMANTICS: [keywords]
    @PURPOSE: [Однострочная суть]
    @LAYER: [Domain | UI | Infra]
@@ -40,7 +40,7 @@
 3. **FOOTER (Подвал):** [/DEF:filename:Module]
 
 ## IV. КОНТРАКТЫ (DESIGN BY CONTRACT & UX)
-Обязательны для TIER: CRITICAL и STANDARD. Заменяют стандартные Docstrings.
+Контракты требуются адаптивно по уровню сложности, а не по жесткому tier.
 
 **[CORE CONTRACTS]:**
 - `@PURPOSE:` Суть функции/компонента.
@@ -62,11 +62,40 @@
 - `@TEST_EDGE: [Название] ->[Сбой]` (Минимум 3: missing_field, invalid_type, external_fail).
 - `@TEST_INVARIANT: [Имя] -> VERIFIED_BY: [scenario_1, ...]`
 
-## V. УРОВНИ СТРОГОСТИ (TIERS)
-Степень контроля задается в Header.
-- **CRITICAL** (Ядро/Деньги/Безопасность): 100% покрытие тегами GRACE. Обязательны: Граф, Инварианты, Логи `logger.reason/reflect`, все `@UX` и `@TEST` теги. Использование `belief_scope` строго обязательно.
-- **STANDARD** (Бизнес-логика / Типовые формы): Базовый уровень. Обязательны: `@PURPOSE`, `@UX_STATE`, `@RELATION`, базовое логирование.
-- **TRIVIAL** (Утилиты / DTO / Атомы UI): Минимальный каркас. Только якоря `[DEF]...[/DEF]` и `@PURPOSE`.
+## V. ШКАЛА СЛОЖНОСТИ (COMPLEXITY 1-5)
+Степень контроля задается в Header через `@COMPLEXITY` или сокращение `@C`.
+Если тег отсутствует, сущность по умолчанию считается **Complexity 1**. Это сделано специально для экономии токенов и снижения шума на очевидных утилитах.
+
+- **1 — ATOMIC**
+  - Примеры: DTO, исключения, геттеры, простые утилиты, короткие адаптеры.
+  - Обязательны только якоря `[DEF]...[/DEF]`.
+  - `@PURPOSE` желателен, но не обязателен.
+
+- **2 — SIMPLE**
+  - Примеры: простые helper-функции, небольшие мапперы, UI-атомы.
+  - Обязателен `@PURPOSE`.
+  - Остальные контракты опциональны.
+
+- **3 — FLOW**
+  - Примеры: стандартная бизнес-логика, API handlers, сервисные методы, UI с загрузкой данных.
+  - Обязательны: `@PURPOSE`, `@RELATION`.
+  - Для UI дополнительно обязателен `@UX_STATE`.
+
+- **4 — ORCHESTRATION**
+  - Примеры: сложная координация, работа с I/O, multi-step алгоритмы, stateful pipelines.
+  - Обязательны: `@PURPOSE`, `@RELATION`, `@PRE`, `@POST`, `@SIDE_EFFECT`.
+  - Для Python обязателен осмысленный путь логирования через `logger.reason()` / `logger.reflect()` или аналогичный belief-state механизм.
+
+- **5 — CRITICAL**
+  - Примеры: auth, security, database boundaries, migration core, money-like invariants.
+  - Обязателен полный контракт: уровень 4 + `@DATA_CONTRACT` + `@INVARIANT`.
+  - Для UI требуются UX-контракты.
+  - Использование `belief_scope` строго обязательно.
+
+**Legacy mapping (обратная совместимость):**
+- `@TIER: TRIVIAL` -> Complexity 1
+- `@TIER: STANDARD` -> Complexity 3
+- `@TIER: CRITICAL` -> Complexity 5
 
 ## VI. ПРОТОКОЛ ЛОГИРОВАНИЯ (THREAD-LOCAL BELIEF STATE)
 Логирование — это механизм трассировки рассуждений ИИ (CoT) и управления Attention Energy. Архитектура использует Thread-local storage (`_belief_state`), поэтому `ID` прокидывается автоматически.
@@ -90,11 +119,11 @@
 
 ## VII. АЛГОРИТМ ИСПОЛНЕНИЯ И САМОКОРРЕКЦИИ
 **[PHASE_1: ANALYSIS]**
-Оцени TIER, Layer и UX-требования. При слепоте контекста -> `yield [NEED_CONTEXT: id]`.
+Оцени Complexity, Layer и UX-требования. При слепоте контекста -> `yield [NEED_CONTEXT: id]`.
 **[PHASE_2: SYNTHESIS]**
-Сгенерируй каркас из `[DEF]`, Header и Контрактов.
+Сгенерируй каркас из `[DEF]`, Header и только тех контрактов, которые соответствуют уровню сложности.
 **[PHASE_3: IMPLEMENTATION]**
-Напиши код строго по Контракту. Для CRITICAL секций открой `with belief_scope("ID"):` и орошай путь вызовами `logger.reason()` и `logger.reflect()`.
+Напиши код строго по Контракту. Для Complexity 5 секций открой `with belief_scope("ID"):` и орошай путь вызовами `logger.reason()` и `logger.reflect()`.
 **[PHASE_4: CLOSURE]**
 Убедись, что все `[DEF]` закрыты соответствующими `[/DEF]`.