diff --git a/docs/prompt_for_opus_review.md b/docs/prompt_for_opus_review.md
new file mode 100644
index 0000000..2dea2a2
--- /dev/null
+++ b/docs/prompt_for_opus_review.md
@@ -0,0 +1,41 @@
+# Промпт для Opus 4.8: код-ревью и оценка архитектуры (3 задачи roadmap)
+
+Дата: 2026-09-22 | Статус: для отправки
+
+```text
+Роль: ревьюер архитектуры Go-провайдера Terraform.
+
+ПРАВИЛА:
+- Файлы НЕ открывай, в репозиторий не лезь — отвечай только по контексту ниже.
+- Анализируй ТОЛЬКО 3 указанные задачи, не весь проект.
+- Ответ максимально сжатый: только выводы/риски/рекомендации. Без вводных, без «рассмотрим», без повторов. Списки или таблица. Риск помечай 🔴/🟡/🟢.
+- Если для ответа не хватает факта — пиши «НЕДОСТАТОЧНО ДАННЫХ: …», не выдумывай.
+
+КОНТЕКСТ (достаточен, файлы не нужны):
+- terraform-provider-nubes, Go, terraform-plugin-framework v1.8.0. Ресурсы ГЕНЕРИРУЮТСЯ из YAML-спек сервисов (не рукописные).
+- Один сервис → один ресурс инстанса nubes_<service> (CRUD). В YAML: operations (create/modify/suspend/…), params с type (bool/int64/string/map-fixed/array-map-fixed), required, default, is_modifiable, ref_svc_id.
+- Schema: param → Required (если required, без default, не refSvc); Optional; Computed+Default (если default); Optional+Computed (если параметр читается обратно из state_params инстанса, или это JSON).
+- Create: резолвит refSvc-параметры (принимают display name ИЛИ UUID → uid в API), вызывает create-op, затем читает state обратно.
+- Update: если изменились modify-параметры → вызывает modify-op с ними. ModifyPlan запрещает менять create-only атрибуты (ошибка).
+- Read: читает state_params инстанса обратно в input-поля (drift), и выставляет computed-мапы: state_params, state_out, state_params_flat, state_out_flat + vault_*.
+- Delete: suspend / delete / state_only — в зависимости от наличия suspend-op у сервиса.
+- Межресурсные зависимости: пользователь в .tf ссылается на атрибуты других ресурсов (напр. nubes_vc_vdc.vdc.id). ref_svc_id валидирует значение по инстансам целевого сервиса и резолвит в uid.
+- Data sources НЕ генерируются (только ресурсы).
+- map-fixed → SingleNestedAttribute (HCL: `x = { … }`); array-map-fixed → StringAttribute (JSON-строка).
+- Сервисы: vc_org (19), vc_vdc (21), vc_nsxt (22). Спека k8s_shturval уже есть.
+
+УЖЕ СДЕЛАНО: vcVdc create, vcNsxt create — работают (v2.0.8).
+
+АНАЛИЗИРОВАТЬ (только это):
+1. vcOrg modify — аллокация внешних IP в организацию ПО МЕРЕ НЕОБХОДИМОСТИ (динамически, число заранее не фиксировано).
+2. vcNsxt modify — включить SNAT и указать внешний IP, взятый из уже аллоцированного пула vcOrg.
+3. k8sShturval create.
+
+ВОПРОСЫ (ответь по пунктам, кратко):
+1. Покрывает ли текущая модель эти 3 задачи, или для какой-то нужна новая абстракция (data source / action / subresource)? По каждой задаче — вердикт.
+2. vcOrg IP-аллокация: как моделировать пул внешних IP, растущий по мере необходимости — (а) атрибут-массив на nubes_vc_org, (б) отдельный ресурс/подресурс на каждый IP? Что лучше согласуется с текущей архитектурой и почему.
+3. vcNsxt: как передать «внешний IP из vcOrg»? Сравни: (а) refSvc-параметр, (б) computed-атрибут vcOrg + ссылка nubes_vc_org.<name>.<attr>, (в) data source. Учти ограничение: refSvc ссылается на инстанс/uid, но не на конкретный элемент списка.
+4. Риски текущего кода именно для этих потоков: update/modify с массивными параметрами; create-only guard; read-back; порядок плана между зависимыми ресурсами.
+5. k8sShturval create: что критично проверить (refSvc к vdc/org, долгий create, типы параметров)?
+6. Итог: 3–5 конкретных рекомендаций по приоритету — что добавить/изменить в генераторе или ресурсах.
+```