diff --git a/TASKS/universal-mock-generator-prompt.md b/TASKS/universal-mock-generator-prompt.md
new file mode 100644
index 0000000..ae0b8be
--- /dev/null
+++ b/TASKS/universal-mock-generator-prompt.md
@@ -0,0 +1,140 @@
+# Задача: универсальный генератор моков из STANDS YAML
+
+## Контекст
+
+**app-autotest** — тестирует сервисы Nubes. Для интеграционных тестов проектируется
+**мок-полигон** — Flask-заглушка, притворяющаяся Nubes API.
+
+Архитектура полигона уже спроектирована: см. `DOCS/polygon-plan.md`.
+Ключевое решение: data-driven, сервисы описываются в YAML, эмулятор универсальный.
+
+**Открытие:** в `STANDS/test/resources_yaml/` лежат 37 YAML-файлов, которые
+генерит приложение для Terraform-провайдера. Эти YAML описывают ВСЕ сервисы
+в универсальном формате — провайдер обрабатывает их без привязки к особенностям.
+
+**Идея:** использовать эти YAML как источник для автоматической генерации
+конфигов мок-полигона. Не писать YAML вручную — конвертировать из STANDS.
+
+## Что прочитать Опусу (обязательно)
+
+1. **`DOCS/polygon-plan.md`** — полный план полигона (369 строк)
+2. **`STANDS/test/resources_yaml/1_dummy.yaml`** — Болванка (339 строк, простой)
+3. **`STANDS/test/resources_yaml/90_postgres.yaml`** — PostgreSQL (934 строки, САМЫЙ сложный: 10+ операций, create_user/create_database, map-fixed с sub_params, resourceRealm)
+4. **`STANDS/test/resources_yaml/150_k8s_sthutrval_cluster.yaml`** — K8s (371 строка, умеренно сложный)
+5. **`STANDS/test/resources_yaml/115_mariadb.yaml`** — MariaDB (460 строк, похож на PG)
+6. **`STANDS/test/resources_yaml/27_vc_vm_v2.yaml`** — VM v2 (71 строка, простой)
+7. **`STANDS/test/resources_yaml/21_vc_vdc.yaml`** — vDC (169 строк, инфраструктурный)
+
+**НЕ читать:** остальные DOCS, HISTORY, JS-файлы. Только polygon-plan и 6 YAML.
+
+## Ключевой вопрос
+
+Можно ли построить **универсальный конвертер** STANDS YAML → polygon-конфиг,
+который работает для ВСЕХ 37 сервисов без сервис-специфичного кода?
+
+Если да — спроектировать его архитектуру. Если нет — объяснить где проходит
+граница универсальности и что придётся делать вручную.
+
+## Что исследовать
+
+### 1. Формат STANDS YAML — полнота и единообразие
+
+Сравни 6 YAML-файлов (от простого dummy до сложного postgres). Ответь:
+
+- Все ли поля, нужные полигону, присутствуют в STANDS YAML?
+- Одинакова ли структура у всех 37 сервисов? Есть ли сервисы с нестандартной структурой?
+- Покрывает ли STANDS YAML все типы параметров: string, integer, boolean, map, map-fixed, array, array(map)?
+- Есть ли в STANDS YAML информация о valueList, refSvcId, dataDescriptor — или это нужно достраивать?
+
+### 2. stateParams — генерация из create-операции
+
+После create полигон должен отдавать `state.params` с ТЕКУЩИМИ значениями.
+В STANDS YAML у create-операции есть `params[].default` — можно ли их использовать?
+
+- Для всех ли сервисов create-операция имеет defaults для всех параметров?
+- Как быть с параметрами без default? Брать из `default_for(dataType)`?
+- Как мапятся `sub_params` (map-fixed) в state.params? Пример из postgres: `clusterConfiguration.replicas` → как это выглядит в state.params?
+
+### 3. stateOut — генерация из операций
+
+Для PostgreSQL `state.out = {users: {pgadmin: {}}, databases: {mydb: {}}}`.
+
+В STANDS YAML у postgres есть операции `create_user` и `create_database`.
+Можно ли по наличию таких операций автоматически сгенерировать структуру stateOut?
+
+- У каких ещё сервисов есть `create_user`/`create_database`? (MariaDB, ClickHouse?)
+- Есть ли другие паттерны stateOut кроме users/databases?
+- Можно ли вывести правило: «если есть операция create_X → добавить X в stateOut»?
+
+### 4. Маппинг полей 1:1
+
+Составь таблицу маппинга STANDS YAML → polygon-конфиг для ВСЕХ полей.
+Пример (начало):
+
+| STANDS YAML | Polygon config |
+|---|---|
+| `service_id` | `serviceId` |
+| `name` | `svc` |
+| `operations[].id` | `svcOperationId` |
+| `operations[].name` | `operation` |
+| `params[].id` | `svcOperationCfsParamId` |
+| `params[].code` | `svcOperationCfsParam` |
+| `params[].data_type` | `dataType` |
+| `params[].sub_params` | `dataDescriptor` |
+
+Какие поля НЕ мапятся 1:1 и требуют трансформации?
+
+### 5. Операции — какие включать
+
+В STANDS YAML у postgres 10+ операций: create, delete, modify, suspend, resume,
+restart, recovery, create_user, delete_user, create_database, delete_database.
+
+Полигону нужны 6: create, modify, delete, suspend, resume, redeploy.
+
+- У всех ли сервисов есть эти 6 операций?
+- Что делать с «лишними» операциями (restart, recovery, create_user...)?
+- Нужно ли их включать в мок? Если да — как они влияют на stateParams/stateOut?
+
+### 6. resourceRealm и refSvcId
+
+У многих сервисов есть параметр `resourceRealm` (ссылка на платформу k8s/vDC).
+В полигоне refSvcId в MVP игнорируется (validate-cfs всегда OK).
+
+- Достаточно ли просто принимать любое значение resourceRealm?
+- Или нужно чтобы эмулятор возвращал реалистичный valueList для resourceRealm?
+- Есть ли другие refSvcId-параметры кроме resourceRealm?
+
+### 7. Краевые случаи
+
+- Сервисы с `kind: user` или `kind: database` операциями — как их обрабатывать?
+- Сервисы с `adopt_existing_on_create_default: true` — нужно ли эмулировать adopt?
+- Есть ли сервисы где create-операция отсутствует (только modify/delete)?
+- Параметры с `func: getAvailableResourceRealms` — динамический valueList, как эмулировать?
+
+### 8. Архитектура конвертера
+
+Если универсальный подход возможен — спроектировать модуль `polygon/from_stands.py`:
+
+- Какие входы (путь к STANDS, фильтр сервисов)?
+- Алгоритм конвертации одного YAML → polygon-конфиг
+- Генерация stateParams (из create defaults + default_for)
+- Генерация stateOut (из операций create_user/create_database)
+- Обработка sub_params → dataDescriptor
+- Что делать с полями которые не мапятся (man, descr, sort, func)?
+- Выходной формат: один общий JSON/dict или отдельные YAML в `polygon/services/`?
+
+## Ожидаемый ответ
+
+1. **Вердикт:** возможен ли универсальный конвертер для всех 37 сервисов?
+2. **Таблица маппинга:** все поля STANDS → polygon с пометками «1:1», «трансформация», «игнорировать»
+3. **Алгоритм конвертации:** пошагово, с примерами для dummy и postgres
+4. **Границы универсальности:** что НЕ покрывается автоматически и требует ручной доработки
+5. **Архитектура from_stands.py:** структура модуля, функции, поток данных
+6. **Изменения в polygon-plan.md:** что нужно поправить в существующем плане
+
+## Ограничения
+
+- Только Python (PyYAML для чтения STANDS)
+- Результат — данные для MockState, НЕ код самого эмулятора
+- Конвертер запускается один раз при старте полигона (или offline при сборке)
+- Никаких внешних API, только чтение локальных YAML-файлов