semantic protocol update

.ai/standards/semantics.md

@@ -5,6 +5,7 @@
 
 #### I. ЗАКОН (АКСИОМЫ)
 1. Смысл первичен. Код вторичен.
+2.Слепота недопустима. Если узел графа (@RELATION) или схема данных неизвестны — не выдумывай реализацию. Остановись и запроси контекст.
 2. Контракт (@PRE/@POST) — источник истины.
 **3. UX — это логика, а не декор. Состояния интерфейса — часть контракта.**
 4. Структура `[DEF]...[/DEF]` — нерушима.
@@ -47,11 +48,13 @@
   @PRE: Входные условия.
   @POST: Гарантии выхода.
   @SIDE_EFFECT: Мутации, IO.
+  @DATA_CONTRACT: Ссылка на DTO/Pydantic модель. Заменяет ручное описание @PARAM. Формат: Input -> [Model], Output -> [Model].
   
 **UX Теги (Svelte/Frontend):**
   **@UX_STATE:** `[StateName] -> Визуальное поведение` (Idle, Loading, Error).
   **@UX_FEEDBACK:** Реакция системы (Toast, Shake, Red Border).
   **@UX_RECOVERY:** Механизм исправления ошибки пользователем (Retry, Clear Input).
+  **@UX_REATIVITY:** Явное указание использования рун. Формат: State: $state, Derived: $derived. Никаких устаревших export let.
   
 **UX Testing Tags (для Tester Agent):**
   **@UX_TEST:** Спецификация теста для UX состояния.
@@ -63,41 +66,26 @@
 #### V. АДАПТАЦИЯ (TIERS)
 Определяется тегом `@TIER` в Header.
 
-1. **CRITICAL** (Core/Security/**Complex UI**):
+### V. УРОВНИ СТРОГОСТИ (TIERS)
-   - Требование: Полный контракт (включая **все @UX теги**), Граф, Инварианты, Строгие Логи.
+Степень контроля задается тегом `@TIER` в Header.
-   ```
-   @TEST_CONTRACT: Обязательное описание структуры входных/выходных данных.
-   Формат:
-   @TEST_CONTRACT: Name -> {
-      required_fields: {field: type},
-      optional_fields: {field: type},
-      invariants: [...]
-   }
 
-   @TEST_FIXTURE: Эталонный корректный пример (happy-path).
+**1. CRITICAL** (Ядро / Безопасность / Сложный UI)
-   Формат:
+- **Закон:** Полный GRACE. Граф, Инварианты, Строгий Лог, все `@UX` теги.
-   @TEST_FIXTURE: fixture_name -> {INLINE_JSON | PATH#fragment}
+- **Догма Тестирования:** Тесты рождаются из контракта. Голый код без данных — слеп.
+  - `@TEST_CONTRACT: InputType -> OutputType`. (Строгий интерфейс).
+  - `@TEST_SCENARIO: name -> Ожидаемое поведение`. (Суть теста).
+  - `@TEST_FIXTURE: name -> file:PATH | INLINE_JSON`. (Данные для Happy Path).
+  - `@TEST_EDGE: name -> Описание сбоя`. (Минимум 3 границы). 
+    - *Базовый предел:* `missing_field`, `empty_response`, `invalid_type`, `external_fail`.
+  - `@TEST_INVARIANT: inv_name -> VERIFIED_BY: [scenario_1, ...]`. (Смыкание логики).
+- **Исполнение:** Tester Agent обязан строить проверки строго по этим тегам.
 
-   @TEST_EDGE: Граничные случаи (минимум 3 для CRITICAL).
+**2. STANDARD** (Бизнес-логика / Формы)
-   Формат:
+- **Закон:** База. (`@PURPOSE`, `@UX_STATE`, Лог, `@RELATION`).
-   @TEST_EDGE: case_name -> {INLINE_JSON | special_case}
+- **Исключение:** Для сложных форм внедряй `@TEST_SCENARIO` и `@TEST_INVARIANT`.
 
-   @TEST_INVARIANT: Обязательно. Связывает тесты с инвариантами.
+**3. TRIVIAL** (DTO / Атомы UI / Утилиты)
-   Формат:
+- **Закон:** Каркас. Только якорь `[DEF]` и `@PURPOSE`. Данные и графы не требуются.
-   @TEST_INVARIANT: invariant_name -> verifies: [test_case_1, test_case_2]
-
-   Обязательные edge-типы для CRITICAL:
-   - missing_required_field
-   - empty_response
-   - invalid_type
-   - external_failure (exception)
-   ```
-   - Tester Agent **ОБЯЗАН** использовать @TEST_CONTRACT, @TEST_FIXTURE и @TEST_EDGE при написании тестов для CRITICAL модулей.
-2. **STANDARD** (BizLogic/**Forms**):
-   - Требование: Базовый контракт (@PURPOSE, @UX_STATE), Логи, @RELATION.
-   - @TEST_INVARIANT, @TEST_CONTRACT: Рекомендуется для Complex Forms.
-3. **TRIVIAL** (DTO/**Atoms**):
-   - Требование: Только Якоря [DEF] и @PURPOSE.
 
 #### VI. ЛОГИРОВАНИЕ (ДАО МОЛЕКУЛЫ / MOLECULAR TOPOLOGY)
 Цель: Трассировка. Самокоррекция. Управление Матрицей Внимания ("Химия мышления").
@@ -129,10 +117,16 @@
 
 **Незыблемое правило:** Всякому логу системы — тавро `source`. Для Внешенго Мира (Svelte) начертай рунами вручную: `console.log("[ID][REFLECT] Msg")`.
 
-#### VII. АЛГОРИТМ ГЕНЕРАЦИИ
+#### VIII. АЛГОРИТМ ГЕНЕРАЦИИ И ВЫХОД ИЗ ТУПИКА
-1. АНАЛИЗ. Оцени TIER, слой и UX-требования.
+1. АНАЛИЗ. Оцени TIER, слой и UX-требования. Чего не хватает? Запроси `[NEED_CONTEXT: id]`.
 2. КАРКАС. Создай `[DEF]`, Header и Контракты.
-3. РЕАЛИЗАЦИЯ. Напиши логику, удовлетворяющую Контракту (и UX-состояниям).
+3. РЕАЛИЗАЦИЯ. Напиши логику, удовлетворяющую Контракту (и UX-состояниям). Орошай путь логами `[REASON]` и `[REFLECT]`.
 4. ЗАМЫКАНИЕ. Закрой все `[/DEF]`.
 
+**РЕЖИМ ДЕТЕКТИВА (Если контракт нарушен):**
+ЕСЛИ ошибка или противоречие -> СТОП. 
+1. Выведи `[COHERENCE_CHECK_FAILED]`.
+2. Сформулируй гипотезу: `[EXPLORE] Ошибка в I/O, состоянии или зависимости?`
+3. Запроси разрешение на изменение контракта или внедрение отладочных логов.
+
 ЕСЛИ ошибка или противоречие -> СТОП. Выведи `[COHERENCE_CHECK_FAILED]`.