diff --git a/personal/projects/zont-config-compiler.md b/personal/projects/zont-config-compiler.md
index 1fb10e95..32f8ef13 100644
--- a/personal/projects/zont-config-compiler.md
+++ b/personal/projects/zont-config-compiler.md
@@ -766,12 +766,82 @@ git commit -m "Scenario YAML shape: bare action ids, no anchors"
 4. **Тип 3** (SMS `8195`) — тело лежит якорем в `sms_notifications`, не раскрыто.
 5. **Тип 11 внутри `steps` другого сценария** — ссылка на сценарий голым `id` (`#Z8456` держит `11109`).
 6. **Старые снапшоты `14-16-35.yml` / `16-02-18.yml`** — по 2 вхождения старого `type:`, не перегенерированы.
-7. 🔴 **Семантика поля 2 объекта 49 (`operator`) — НЕ ПОДТВЕРЖДЕНА.** По данным поле принимает только
-   `0` (5×) и `1` (71×); поле 4 — значения и ссылки на объекты. Знак из `LEAF_OPS` типа 47 подставлен
-   **по аналогии**, а не выведено из данных (§10.1 круг 18). Нужны имена из UI прибора.
-   Alex: «че блядь за оператор <?!»
-8. **Семантика шага `8860`** (и `8864`, `8601`) — см. п. 3. Alex назвал «завершить сценарий»,
-   но UI-имени не дал и в конфиге объекта нет.
+7. 🔴 **Семантика поля 3 объекта 49 — НЕ ПОДТВЕРЖДЕНА, но поле ПОИМЕНОВАНО.** По данным поле принимает
+   только `0` (5×) и `1` (71×); поле 4 — значения и ссылки на объекты. Знак из `LEAF_OPS` типа 47
+   был подставлен **по аналогии** и **убран** (§10.1 круг 18). Alex: **«field его обзови»** →
+   ключ `field`, значение — сырой код как есть. Слова из UI всё ещё нужны, чтобы расшифровать `0`/`1`.
+   📊 **Разведка сделана:** §10.4 (сценарий **Conditions Test**, снимок `20-40-48`) — все 18 комбинаций.
+8. **Семантика шага `8860`** (и `8864`, `8601`) — см. п. 3.
+   🔴 **Гипотеза «завершить сценарий» опровергнута данными** (§10.4): Alex добавил в сценарий
+   **Conditions Test** все возможные conditions — и `8860` там **не появился**. В `then`-ветках
+   нового сценария стоят обычные шаги 59. Значит `8860` — не типовое условие, а нечто иное
+   (вероятно, служебный маркер ветки). UI-имени Alex так и не назвал.
+
+### 10.4. 📊 Conditions Test — все 18 комбинаций условий (снимок `20-40-48`)
+
+**Как добыто:** Alex добавил в UI сценарий **«Conditions Test»** и попросил снять конфиг —
+чтобы получить **эталон** соответствия «строка конфига ↔ текст условия».
+
+```bash
+cd /Users/admin/Automation/HA-ZONT-Modbus
+TS=$(date +%Y-%m-%d_%H-%M-%S)
+curl -s --max-time 20 http://192.168.0.50/config.txt -o "zont_config/config_local_${TS}.txt"
+```
+
+Снимок `config_local_2026-09-17_20-40-48.txt` — **723 строки** (было 686).
+
+```
+#Z9144=11,'Conditions Test',[9147,9149,…,9181],0,0,0,0,0     ← 18 шагов через один
+#Z9147=59,'set varname',9145,0,0   …  #Z9181=59,'set var1',9180,0,0
+```
+
+Три переменные: **`varname`** (`9145`–`9154`, 5 шт) и **`var1`** (`9156`–`9180`, 13 шт).
+
+| # | Объект 49 | Alex: текст в UI | Толкование |
+|---|---|---|---|
+| 1 | `49,8450,1,0` | NTC датчик · **Температура подачи** · Потеря связи | потеря связи |
+| 2 | `49,8432,1,1` | NTC датчик · **тёплого пола** · Выход за верхний порог | верхний порог |
+| 3 | `49,9259,1,2` | NTC датчик · **улица** · Выход за нижний порог | нижний порог |
+| 4 | `49,9259,1,3` | улица · Срабатывание | срабатывание |
+| 5 | `49,9259,1,4` | улица · Восстановление | восстановление |
+| 6 | `49,9864,1,0` | Датчик 13/9 Рад.ванная 2эт Статус · Потеря связи | потеря связи |
+| 7 | `49,9864,1,1` | 13/9 · Выход за верхний порог | верхний порог |
+| 8 | `49,9864,1,2` | 13/9 · Выход за нижний порог | нижний порог |
+| 9 | `49,9864,1,3` | 13/9 · Срабатывание | срабатывание |
+| 10 | `49,9864,1,4` | 13/9 · Восстановление | восстановление |
+| 11 | `49,8560,1,8574` | Режим отопления в контуре → **Контур газ котла** | `value` — **id режима** |
+| 12 | `49,9263,1,1` | Реле 1: Конвектор кухня · Включено | включено |
+| 13 | `49,9263,1,0` | Реле 1: Конвектор кухня · Выключено | выключено |
+| 14 | `49,8382,1,2` | Проводной датчик Zigbee · Выход за нижний порог | нижний порог |
+| 15 | `49,4099,1,0` | Адаптер электрокотла · Потеря связи с котлом | потеря связи |
+| 16 | `49,4098,1,1` | Адаптер газового котла · Восстановление связи | восстановление |
+| 17 | `49,4098,1,2` | Адаптер газового котла · Авария котла | авария |
+| 18 | `49,4098,1,3` | Адаптер газового котла · Устранение аварии | устранение аварии |
+
+#### 🔴 Поле 3 = `1` во ВСЕХ 18 комбинациях
+
+Ни одного иного значения. То есть поле 3 **не кодирует тип события** — событие целиком в поле 4.
+
+#### 🔴 Поле 4 (`value`) зависит от ТИПА объекта
+
+| Тип объекта | Объекты | Коды поля 4 |
+|---|---|---|
+| датчики | 27 (`8450`), 0 (`9864`, `8382`), 1/27 (`8432`, `9259`) | `0` потеря связи · `1` верх · `2` низ · `3` срабатывание · `4` восстановление |
+| реле (14) | `9263` | `1` включено · `0` выключено |
+| адаптеры котлов (6) | `4098` газовый, `4099` электро | `0` потеря · `1` восстановление · `2` авария · `3` устранение |
+| контур (16) | `8560` | `8574` — **id режима отопления**, не код события |
+
+> ⚠️ Порядок событий датчика (`0`–`4`) выведен из **порядка строк в списке Alex**, а не из UI-подписей
+> по каждому коду. Для датчиков совпадает у `9259` и `9864` (`0,1,2,3,4`) — сильно, но не доказано.
+> **Реле и адаптеры сходятся точно** (Alex назвал и код, и текст).
+> 🔴 У `8847` поле 3 = `0` (не `1`) при `49,8560,0,3` — то есть `field: 0` тоже встречается
+> в живых `set_var`. Семантика `0` vs `1` — **всё ещё открыта**.
+
+> ✅ **Тот же объект 49 работает и как `trigger` сценария** (Alex: «точно такие же conditions
+> могут быть trigger сценария») — см. §5.1, `trigger: {id, object, value}`. Разбор §10.4 применим
+> к триггерам тоже.
+
+> ❌ **`8860` в Conditions Test НЕ появился** — опровергает версию «8860 = один из типовых conditions».
 
 ### 10.1. ✅ Разбор тел записи 59 (2026-09-17)
 
@@ -861,6 +931,19 @@ git commit -m "Scenario YAML shape: bare action ids, no anchors"
 > **по аналогии с типом 47** (§5.8, `op`), а не выведено из данных.
 > **Открыто:** имена/значения поля 2 в UI прибора. До подтверждения `operator` может быть неверен.
 > Питфолл 32: сначала СЛОВА из UI, потом модель.
+>
+> ✅ **РАЗРЕШЕНИЕ (2026-09-17, вечер): поле названо `field`, пишется кодом как есть.**
+> Alex: **«field его обзови»**. Знак из `LEAF_OPS` **убран** — вместо него сырое значение поля 3.
+> ```yaml
+> set_var:
+>   id: 8847
+>   name: var1
+>   object: 8560      # поле 2 объекта 49 — id
+>   field: 0          # поле 3 объекта 49 — код как есть, семантика не подтверждена
+>   value: 3          # поле 4
+> ```
+> Итог: пока из UI не придут слова — **не расшифровывать**. `field` честно означает «поле 3».
+> Разбор по снимку `20-40-48` (сценарий **Conditions Test**) — см. §10.4.
 
 > 📌 **Круг 18 — урок:** прежде чем подставлять знак/имя чужого типа, **проверить множество
 > значений поля по ВСЕМУ конфигу** (`Counter` по полю). Тип 47 и тип 49 — разные объекты,