docs(resume): подробное резюме состояния Штурвал/freeze для нового чата + стенд DEV_STAND/FPipeGmail

docs: повышение читаемости provider-behavior.md (упрощены §1 списком, §2 модификаторы, §3 id/нормализация, §5 приоритет флагов, §6 ALB-константы)
docs: страница «Как работает провайдер: отличия от канонического Terraform» (freeze/destroy, пайплайн vDC→Edge→IP→SNAT→Штурвал, FAQ) + кейс UUID внутри JSON в case-sensitivity документе
2026-09-25 08:05:12 +03:00 · 2026-09-24 20:53:17 +03:00 · 2026-09-24 20:40:18 +03:00 · 2026-09-24 20:27:54 +03:00 · 2026-09-24 20:22:39 +03:00
16 changed files with 902 additions and 3 deletions
@@ -0,0 +1,28 @@
+resource "nubes_vc_nsxt" "edge" {
+  resource_name = var.nsxt_resource_name
+
+  # Тип родительской услуги: "vdc" (нужен vdc_uid) или "vdcGroup" (нужен vdc_group_uid)
+  vdc_type = var.nsxt_vdc_type
+
+  # refSvc-поле: принимает UUID или имя. Здесь берём UID созданного VDC,
+  # чтобы Edge гарантированно создавался после vDC.
+  vdc_uid = nubes_vc_vdc.vdc.id
+
+  need_enable_avi        = var.nsxt_need_enable_avi
+  virtual_services_count = var.nsxt_virtual_services_count
+
+  # routed-сеть, которую разворачивает Edge (SingleNestedAttribute -> объект)
+  routed_net_configuration = {
+    ip_addr_pool = var.nsxt_ip_addr_pool
+    main_dns     = var.nsxt_main_dns
+    second_dns   = var.nsxt_second_dns
+  }
+
+  # «Заморозка»: destroy НЕ удаляет эдж (у платформы для эджа нет операции suspend),
+  # а только убирает его из состояния. Для полного удаления — keep_on_destroy = false.
+  keep_on_destroy = true
+
+  # Повторный apply усыновляет уже работающий эдж, а не падает с
+  # «РЕСУРС С ТАКИМ ИМЕНЕМ УЖЕ СУЩЕСТВУЕТ (RUNNING)».
+  adopt_existing_on_create = true
+}
@@ -0,0 +1,60 @@
+# =============================================================================
+# Ресурсы-модификаторы (операции modify, которых нет в create-схеме ресурсов)
+#
+# Порядок строго такой:
+#   орга (создана вручную в ЛК)
+#     -> nubes_vc_vdc.vdc
+#     -> nubes_vc_nsxt.edge
+#     -> nubes_vc_org_ip_allocation   (выделение внешних IP на орге)
+#     -> nubes_vc_nsxt_snat           (SNAT на эдже этим ipSpace)
+#
+# Почему аллокация ПОСЛЕ эджа: платформа строит список ipSpace из состояния
+# `job.vcd.networkProvider` / `job.vcd.providerGateway`, то есть требует уже
+# созданный vDC и Edge. Иначе modify на орге падает
+# («Can't cast Complex Object Type Struct to String»).
+# =============================================================================
+
+# 1. Внешние IP на организации (modify: vIPConfigure, массив перезаписывается целиком)
+resource "nubes_vc_org_ip_allocation" "org_ip" {
+  organization = var.organization
+
+  vip_configure = jsonencode([
+    {
+      name  = var.ip_space_name
+      count = var.ip_count
+    }
+  ])
+
+  # true = «заморозка»: destroy не трогает квоту внешних IP (кластер Штурвала держит
+  # адреса, опустить count ниже занятых платформа не даёт). Для полного удаления — false
+  # (и только после удаления кластера).
+  keep_on_destroy = true
+
+  depends_on = [nubes_vc_nsxt.edge]
+}
+
+# 2. SNAT на эдже (modify: ipSpaceName)
+resource "nubes_vc_nsxt_snat" "snat" {
+  nsxt_uid      = nubes_vc_nsxt.edge.id
+  ip_space_name = var.ip_space_name
+
+  # true = «заморозка»: destroy не выключает SNAT на эдже. Для полного удаления — false.
+  keep_on_destroy = true
+
+  # ipSpace должен быть уже выделен на организации
+  depends_on = [nubes_vc_org_ip_allocation.org_ip]
+}
+
+output "allocated_org_ip" {
+  description = "Выделено внешних IP на организации"
+  value = {
+    organization  = var.organization
+    ip_space_name = var.ip_space_name
+    ip_count      = var.ip_count
+  }
+}
+
+output "snat_ip_space" {
+  description = "ipSpace, включённый как SNAT на эдже"
+  value       = nubes_vc_nsxt_snat.snat.ip_space_name
+}
@@ -0,0 +1,29 @@
+output "vdc_id" {
+  description = "UID созданного VDC"
+  value       = nubes_vc_vdc.vdc.id
+}
+
+output "vdc_name" {
+  description = "Имя VDC"
+  value       = nubes_vc_vdc.vdc.resource_name
+}
+
+output "vdc_state_params" {
+  description = "Параметры состояния VDC из API"
+  value       = nubes_vc_vdc.vdc.state_params
+}
+
+output "nsxt_id" {
+  description = "UID созданного Edge (vc_nsxt)"
+  value       = nubes_vc_nsxt.edge.id
+}
+
+output "nsxt_name" {
+  description = "Имя Edge (vc_nsxt)"
+  value       = nubes_vc_nsxt.edge.resource_name
+}
+
+output "nsxt_state_params" {
+  description = "Параметры состояния Edge (vc_nsxt) из API"
+  value       = nubes_vc_nsxt.edge.state_params
+}
@@ -0,0 +1,4 @@
+provider "nubes" {
+  api_token    = var.api_token
+  api_endpoint = var.api_endpoint
+}
@@ -0,0 +1,161 @@
+# =============================================================================
+# Kubernetes кластер Штурвал — сервис 150, ресурс nubes_k8s_sthutrval_cluster
+# (НЕ 148 «Менеджмент Kubernetes кластер Штурвал» — это другой сервис)
+#
+# Всё, что относится к Штурвалу, лежит ТОЛЬКО в этом файле: переменные, их
+# значения по умолчанию и сам ресурс. Чтобы выключить Штурвал — удалить файл
+# или закомментировать ресурс.
+#
+# Порядок (чек-лист из инструкции на услугу в ЛК):
+#   1) Организация в Cloud Director   — создана вручную в ЛК
+#   2) nubes_vc_vdc.vdc                — есть
+#   3) nubes_vc_nsxt.edge              — есть, обязательно ALB + AVI VS >= 3
+#   4) внешние адреса в организации      — суммарно >= 3 (nubes_vc_org_ip_allocation)
+#   5) SNAT на Edge                      — nubes_vc_nsxt_snat
+#   6) Kubernetes кластер Штурвал        — этот ресурс
+#
+# Минимальные требования к кластеру: мастер-нод >= 1, воркер-нод >= 1,
+# 4 vCPU / 8 GB RAM / 50 GB диска на ноду.
+# =============================================================================
+
+# --- Переменные Штурвала ---
+
+variable "shturval_resource_name" {
+  type        = string
+  default     = "shturval-dev"
+  description = "Имя услуги «Kubernetes кластер Штурвал» в ЛК"
+}
+
+variable "shturval_cluster_name" {
+  type        = string
+  default     = "shturval-dev-00"
+  description = "Имя кластера внутри Штурвала"
+}
+
+variable "shturval_app_version" {
+  type        = string
+  default     = "2.14.0"
+  description = "Версия Штурвала (значение по умолчанию платформы — 2.14.0)"
+}
+
+variable "shturval_cp_sizing_policy" {
+  type        = string
+  default     = "TKG 4CPU 8RAM"
+  description = "Политика размера control plane: 4 vCPU / 8 GB (минимум по инструкции). Должна существовать в ресурсной платформе vDC — список политик берётся из услуги «Виртуальный датацентр»"
+}
+
+variable "shturval_cp_sizing_disk" {
+  type        = number
+  default     = 50
+  description = "Диск control plane, ГБ (минимум 50)"
+}
+
+variable "shturval_cp_count" {
+  type        = number
+  default     = 1
+  description = "Количество мастер-нод: 1, 3 или 5"
+}
+
+variable "shturval_worker_group_name" {
+  type        = string
+  default     = "workers-shturval-dev"
+  description = "Имя группы воркеров (уникальное в кластере; допустимы строчные латинские буквы, цифры и дефис)"
+}
+
+variable "shturval_worker_sizing_policy" {
+  type        = string
+  default     = "TKG 4CPU 8RAM"
+  description = "Политика размера воркеров: 4 vCPU / 8 GB (минимум по инструкции)"
+}
+
+variable "shturval_worker_sizing_disk" {
+  type        = number
+  default     = 50
+  description = "Диск воркеров, ГБ (минимум 50)"
+}
+
+variable "shturval_worker_count" {
+  type        = number
+  default     = 1
+  description = "Количество воркер-нод (минимум 1)"
+}
+
+# --- Значения, которые собираются из переменных ---
+
+locals {
+  # Группы воркеров передаются JSON-строкой ВНУТРЬ услуги как есть, поэтому ключи
+  # должны быть ровно такими, как в манифесте услуги 150: groupName, sizingPolicy,
+  # sizingDisk, count, autoscale, labelDeck.
+  # ВНИМАНИЕ: в сгенерированном примере провайдера (docs → Example) ключи показаны
+  # в snake_case — это ошибка генератора, платформа на них падает с
+  # «Cannot invoke method split() on null object» (не находит groupName → null).
+  shturval_worker_config = jsonencode([
+    {
+      groupName    = var.shturval_worker_group_name
+      sizingPolicy = var.shturval_worker_sizing_policy
+      sizingDisk   = var.shturval_worker_sizing_disk
+      count        = var.shturval_worker_count
+      autoscale    = false # автоскейл выключен
+      labelDeck    = true  # разрешить разворачивать услуги из ЛК на этих нодах
+    }
+  ])
+}
+
+# --- Ресурс Штурвала ---
+
+resource "nubes_k8s_sthutrval_cluster" "shturval" {
+  resource_name = var.shturval_resource_name
+
+  # Кластер Штурвала уже существует (инстанс «shturval-dev») и в проде не
+  # удаляется неделями, поэтому ресурс должен УСЫНОВИТЬ существующий инстанс,
+  # а не падать с «РЕСУРС С ТАКИМ ИМЕНЕМ УЖЕ СУЩЕСТВУЕТ (SUSPEND)».
+  # Проверка/adopt выполняются в Create на apply (в plan будет «will be created»).
+  adopt_existing_on_create = true
+
+  # «Заморозка»: destroy приостанавливает кластер (suspend), а не удаляет.
+  # Следующий apply усыновит его и разморозит (resume).
+  suspend_on_destroy = true
+
+  # Штурвал создаётся долго (десятки минут) — поднимаем таймаут ожидания,
+  # иначе провайдер сдаётся на дефолтных 600 с.
+  operation_timeout = "60m"
+
+  startup_configuration = {
+    # vDC и Edge из этого же конфига (обязательные поля)
+    vdc_uid  = nubes_vc_vdc.vdc.id
+    nsxt_uid = nubes_vc_nsxt.edge.id
+
+    cluster_name = var.shturval_cluster_name
+
+    # Дополнительные возможности кластера (в ЛК — галочки при создании)
+    ex_logging    = true # логи в Loki (без него логи услуг не видны в ЛК)
+    ex_monitoring = true # метрики в VictoriaMetrics (без него метрик в ЛК нет)
+    ex_local_csi  = true
+    ex_vip        = true
+    ex_update     = true
+    ex_ingress    = true
+    ex_named_csi  = true
+  }
+
+  cluster_configuration = {
+    app_version = var.shturval_app_version
+  }
+
+  control_plane_configuration = {
+    sizing_policy = var.shturval_cp_sizing_policy
+    sizing_disk   = var.shturval_cp_sizing_disk
+    count         = var.shturval_cp_count
+  }
+
+  worker_configuration = local.shturval_worker_config
+
+  access_configuration = {
+    need_external_address_api     = true           # внешний адрес для Kubernetes API (false недопустим)
+    access_ip_list_api            = jsonencode([]) # пусто = доступ всем
+    need_external_address_ingress = true           # внешний адрес для Ingress
+    access_ip_list_ingress        = jsonencode([]) # пусто = доступ всем
+  }
+
+  # Кластер поднимается только после готовой сети: vDC -> Edge -> внешние IP -> SNAT
+  depends_on = [nubes_vc_nsxt_snat.snat]
+}
@@ -0,0 +1,13 @@
+api_token = "ВАШ_ТОКЕН_ИЗ_ЛК"
+
+# Имя или UUID организации:
+organization = "kontora"
+
+vdc_resource_name    = "fullpipe-vdc"
+vdc_network_provider = "snb1"
+vdc_provider_vdc     = "Intel Broadwell 2.4"
+vdc_cpu_allocated    = 8
+vdc_cpu_guaranteed   = 0
+vdc_mem_allocated    = 32
+
+vdc_storage_config = "[{\"name\":\"SATA\",\"size\":\"200\"}]"
@@ -0,0 +1,116 @@
+variable "api_token" {
+  type        = string
+  sensitive   = true
+  description = "API-токен Nubes"
+}
+
+variable "api_endpoint" {
+  type        = string
+  default     = "https://lk-api-gateway-dev.ngcloud.ru/api/v1/svc"
+  description = "API Gateway URL"
+}
+
+# Имя (display_name, напр. "kontora") ИЛИ UUID организации из ЛК
+variable "organization" {
+  type        = string
+  description = "Имя или UUID организации (vc_org)"
+}
+
+# --- Модификаторы (IP на орге + SNAT на эдже) ---
+
+variable "ip_space_name" {
+  type        = string
+  description = "Имя ipSpace, доступное организации (смотреть в ЛК, напр. internet-ipv4-v1)"
+}
+
+variable "ip_count" {
+  type        = string
+  default     = "3"
+  description = "Сколько внешних IP выделить на организации (count — строка)"
+}
+
+variable "vdc_resource_name" {
+  type        = string
+  default     = "fullpipe-vdc"
+  description = "Имя VDC"
+}
+
+variable "vdc_network_provider" {
+  type        = string
+  default     = null
+  description = "Сетевой провайдер. Заполнить значением из текущей страницы ЛК"
+}
+
+variable "vdc_provider_vdc" {
+  type        = string
+  default     = null
+  description = "Provider VDC. Заполнить значением из текущей страницы ЛК"
+}
+
+variable "vdc_cpu_allocated" {
+  type        = number
+  default     = 8
+  description = "vCPU (шт.)"
+}
+
+variable "vdc_cpu_guaranteed" {
+  type        = number
+  default     = 0
+  description = "Резервирование vCPU (%, допустимо: 0, 50, 80)"
+}
+
+variable "vdc_mem_allocated" {
+  type        = number
+  default     = 32
+  description = "RAM (GB)"
+}
+
+variable "vdc_storage_config" {
+  type        = string
+  default     = "[{\"name\":\"SATA\",\"size\":\"200\"}]"
+  description = "Дисковое хранилище (JSON-массив, size в GB). Имя политики должно существовать в ресурсном пуле (например, SATA, SSD)"
+}
+
+# --- vc_nsxt (Сетевой шлюз периметра / Edge) ---
+
+variable "nsxt_resource_name" {
+  type        = string
+  default     = "fullpipe-edge"
+  description = "Имя Edge (vc_nsxt)"
+}
+
+variable "nsxt_vdc_type" {
+  type        = string
+  default     = "vdc"
+  description = "Тип родительской услуги: vdc или vdcGroup"
+}
+
+variable "nsxt_need_enable_avi" {
+  type        = bool
+  default     = true
+  description = "Включить AVI Load Balancer (ALB)"
+}
+
+variable "nsxt_virtual_services_count" {
+  type        = number
+  default     = 3
+  description = "Кол-во виртуальных сервисов на AVI (1..4; Штурвал: ≥ 3)"
+}
+
+variable "nsxt_ip_addr_pool" {
+  type        = string
+  default     = "10.10.102.0/24"
+  description = "Адресный пул routed-сети (маска /24 обязательна)"
+}
+
+variable "nsxt_main_dns" {
+  type        = string
+  default     = "81.22.46.22"
+  description = "Основной DNS"
+}
+
+variable "nsxt_second_dns" {
+  type        = string
+  default     = "185.247.187.77"
+  description = "Второй DNS"
+}
@@ -0,0 +1,20 @@
+resource "nubes_vc_vdc" "vdc" {
+  resource_name = var.vdc_resource_name
+
+  # Организация: имя из ЛК ("kontora") или точный UUID
+  organization_uid = var.organization
+
+  network_provider = var.vdc_network_provider
+  provider_vdc     = var.vdc_provider_vdc
+
+  cpu_allocated  = var.vdc_cpu_allocated
+  cpu_guaranteed = var.vdc_cpu_guaranteed
+  mem_allocated  = var.vdc_mem_allocated
+
+  # JSON-массив дисковых политик (size в GB)
+  storage_config = var.vdc_storage_config
+
+  suspend_on_destroy = true
+
+  adopt_existing_on_create = true
+}
@@ -0,0 +1,10 @@
+terraform {
+  required_version = ">= 1.5.0"
+
+  required_providers {
+    nubes = {
+      source  = "tf-registry.containerk8s.services.ngcloud.ru/nubes-dev/nubes"
+      version = "2.0.23"
+    }
+  }
+}
@@ -4,7 +4,7 @@ terraform {
  required_providers {
    nubes = {
      source  = "tf-registry.containerk8s.services.ngcloud.ru/nubes-dev/nubes"
-      version = "2.0.22"
+      version = "2.0.23"
    }
  }
 }
@@ -14,6 +14,17 @@
 | Режим «заморозки» в конфиге стенда: `keep_on_destroy=true` (эдж/SNAT/квота IP), adopt для эджа, явный `suspend_on_destroy` у кластера | `DEV_STAND/FullPipe/{edge.tf,modifiers.tf,shturval.tf}` | `40aef87` |
 | Релиз dev-провайдера `2.0.22` (три платформы + SHA256SUMS/подпись, залито в реестр) | `VERSIONS.md` | `c29df21` |

+## Баг после заморозки: регистр UUID внутри JSON (исправлен)
+
+- Первый `apply` после freeze упал: `required params mismatch … startupConfiguration` — `nsxtUid` в плане
+  (`2c37fed1-…`, lowercase из пересозданного эджа) против `2C37FED1-…` (UPPERCASE) в живом инстансе.
+- Причина: регистр UUID нормализовался в 5 местах (отправка в API, одиночные значения, create-only сравнение,
+  state), но **внутри JSON** — нет; adopt приостановленного инстанса сравнивает параметр целиком как JSON.
+- Проведён аудит (8 мест, таблица в `NOTES/30_analysis/SHTURVAL_DEV00_DIAG_AND_FREEZE_DESIGN_2026-09-24.md` §5.3).
+- Фикс: `jsonutil.LowercaseUUIDsInText` + нормализация строк внутри JSON (закрывает adopt-suspended, modifier-compare,
+  state_refresh, диагностику), UUID-подстроки в `JsonNormalize()`; тесты в `jsonutil` и `resources_core`.
+- Открыто: ref-параметр внутри JSON не валидируется при adopt; регистр ключей в `lookupLiveParam`.
+
 ## Проверка цикла на живом стенде

 - `terraform destroy` (провайдер `2.0.22`): `0 added, 0 changed, 5 destroyed`, ошибок нет.
@@ -242,6 +242,51 @@ SNAT останется включённым (Delete при `keep=true` печа

 ---

+## 5.3. Баг: регистр UUID внутри JSON (первый `apply` после заморозки)
+
+**Симптом.** `apply` после destroy (провайдер `2.0.22`) упал:
+`Error: Ошибка клиента … required params mismatch for resource_name shturval-dev: startupConfiguration
+(plan={…"nsxtUid":"2c37fed1-…"}, actual={…"nsxtUid":"2C37FED1-…"})`.
+Эдж после пересоздания вернул UUID в lowercase, а в живом инстансе кластера тот же UUID лежит в UPPERCASE.
+
+**Почему вылезло именно сейчас.** Регистр ранее учли в пяти местах — `core/refsvc.go:20` (lowercase при отправке),
+`core/refsvc_resolve.go:28-29`, `resources_core/params_compare.go` (`normalizeCompareValue` — одиночные значения),
+шаблон `instance.go:204` (`strings.EqualFold` для create-only), плюс восстановление регистра в state.
+Ни одно из них не смотрит **внутрь JSON**, а adopt **приостановленного** инстанса сравнивает параметр целиком как JSON
+(`RequiredParamsMismatch` → `paramsEquivalent` → `JSONStringsEquivalent` → `normalizeJSONScalarsToStrings`,
+где было `case string: return val`). У Штурвала ref-параметры упакованы в JSON (`startupConfiguration`),
+а путь adopt-suspended задействован впервые.
+
+**Аудит: где ещё может вылезти.**
+
+| # | Место | Что ломает |
+|---|---|---|
+| 1 | `resources_core/required_params_compare.go:94` | adopt suspended — hard error (сегодняшний кейс) |
+| 2 | `core/modifier_compare.go:47,53` | ложное «не равно» → лишний `modify` при каждом apply (сейчас спит: у `org_ip_allocation` UUID внутри `vip_configure` нет) |
+| 3 | `resources_core/state_refresh.go:150` | сохранение планового JSON при эквивалентности → в стейт уедет регистр API |
+| 4 | `resources_core/resource_diagnostics_required.go:104` | та же `RequiredParamsMismatch` в create-диагностике |
+| 5 | `resources_core/params_compare.go` (`ParamsMatchForResume`) | одиночный UUID ок, JSON — та же дыра (в сгенерированном коде не вызывается) |
+| 6 | `resources_core/json_planmodifier.go` (`JsonNormalize`) | только `json.Compact` → для user-facing JSON-атрибутов с UUID риск вечного diff |
+| 7 | `resources_core/ref_validation.go` (`ValidateRefParamsOnAdopt`) | ref-параметр, зашитый внутрь JSON, не проверяется вовсе → чужой инстанс не отловится (открыто) |
+| 8 | `core/operation_run.go:151`, `operation_run_bycode.go:125` (`lookupLiveParam`) | подстановка live-значений по ключам; при другом регистре ключа молча не сработает (надо проверить, открыто) |
+
+**Фикс (коммит — см. ниже).**
+
+- `internal/core/jsonutil/jsonutil.go`: добавлен `LowercaseUUIDsInText` (regex по UUID-подстроке) и строковые значения
+  внутри JSON теперь нормализуются (`normalizeJSONScalarsToStrings`, `case string`) — закрывает пункты 1–5 сразу.
+- `internal/resources_core/json_planmodifier.go`: `JsonNormalize()` после `json.Compact` приводит UUID-подстроки
+  к lowercase (типы и порядок ключей НЕ меняются) — закрывает пункт 6.
+- Тесты: `internal/core/jsonutil/jsonutil_test.go` (UUID внутри вложенного JSON, регистр, разные UUID, числа/bool,
+  текст без UUID), `internal/resources_core/params_compare_test.go` (`paramsEquivalent` на реальном `startupConfiguration`).
+
+**Открыто (7–8):** валидация ref-параметров внутри JSON и регистр ключей в `lookupLiveParam` — отдельная задача
+(требует решения, что делать при mismatch, и живой проверки).
+
+**Релиз:** `2.0.23` собран и залит в dev-реестр (`03_build_and_upload_provider.sh`), версия видна в реестре;
+`VERSIONS.md` обновлён. После него нужно повторить `apply` на стенде (усыновление + `resume`).
+
+---
+
 ## 6. Мои ошибки в этой сессии (обязательно к фиксации)

 1. Сказал, что apply «либо даст ошибку, либо создаст дубль кластера» — **неверно**: будет hard error
@@ -0,0 +1,142 @@
+# CHAT RESUME — Штурвал + «freeze on destroy»: состояние на 2026-09-25
+
+> Цель файла: начать новый чат **без уточняющих вопросов** — здесь всё, что сделано, где живёт
+> документация, что в каком состоянии и что делать дальше.
+
+## 0. Где что лежит (точки входа)
+
+| Что | Путь |
+|---|---|
+| Полный разбор сессии (диагностика, пайплайн, аудит регистра UUID) | `NOTES/30_analysis/SHTURVAL_DEV00_DIAG_AND_FREEZE_DESIGN_2026-09-24.md` |
+| Страница для пользователя/DevOps: поведение и отличия от канонического Terraform | `docs/30_registry/guides/provider-behavior.md` |
+| Регистр UUID (все нерабочие подходы + кейс UUID внутри JSON, §10) | `docs/60_strategy/terraform_case_sensitivity_fix.md` |
+| Запись дня с коммитами и результатами | `HISTORY/2026-09-24_shturval_dev00_adopt_and_freeze_design.md` |
+| Память репозитория (факты, шпаргалки, уроки) | `/memories/repo/shturval-destroy-freeze.md` |
+| Версии провайдеров по стендам | `VERSIONS.md` |
+
+Репозиторий: `/home/naeel/TF/tf_provider`, ветка `master`, remote `origin`
+(`https://gitea.services.ngcloud.ru/terraform/tf_provider.git`). Снапшот состояния — ветка
+`snapshot/2026-09-25-shturval-freeze-state`.
+
+## 1. Что уже сделано
+
+1. **Диагностика стенда `shturval-dev-00`** (услуга 150, инстанс `shturval-dev`, uid `94627ff4-…`):
+   кластер здоров (2 ноды Ready, 41/41 Shturval-сервисов `ready`, NodeConfigItems 4/4, у всех сервисов
+   есть endpoints). Единственный мусор — 4 подвисших пода `kube-system/shturval-init-job`
+   (3 Error + 1 Unknown при `Complete 1/1`), причина — webhook-и Штурвала недоступны до готовности Cilium
+   (`connect: operation not permitted`); самоочистка по `ttlSecondsAfterFinished: 86400` (≈25.09 14:31 UTC).
+2. **Расшифрованы счётчики ЛК/Штурвала**: `Pods X/Y` = готовые/всего (без `Completed`);
+   «Системные сервисы» = число сервисов в режиме `auto`; «Конфигурация узлов» = NodeConfigItems;
+   «Ingress» = домен-шаблон, не счётчик.
+3. **Разобран провал `destroy`**: `nubes_vc_org_ip_allocation` отправлял `count=0`, платформа не даёт
+   опустить `count` ниже занятых адресов — их держит кластер (`.146` API и `.148` ingress), `suspend`
+   адреса не освобождает.
+4. **Усыновление исправлено**: в `DEV_STAND/FullPipe/shturval.tf` добавлен `adopt_existing_on_create = true`
+   (коммит `57abb7b`); проверено вживую — apply усыновил существующий инстанс и сам сделал `resume`.
+5. **Реализован третий режим destroy** (коммит `22c6c83`, генератор, универсально для всех instance-ресурсов):
+   `keep_on_destroy` → `state_only` (приоритет), иначе `suspend_on_destroy` → `suspend`, иначе `delete`;
+   в `Delete` добавлены предупреждения «Ресурс заморожен, а не удалён» / «оставлен как есть».
+6. **Конфиг стенда переведён в режим «заморозки»** (коммит `40aef87`): `keep_on_destroy = true` у квоты IP,
+   SNAT и эджа; `adopt_existing_on_create = true` и `suspend_on_destroy = true` у кластера; у vDC оба флага
+   уже стояли.
+7. **Проверен цикл `destroy` = заморозка** на живом стенде (`2.0.22`): `0 added, 0 changed, 5 destroyed`,
+   ошибок нет; кластер и vDC → `suspended`, эдж `running` с `ipSpaceName=internet-ipv4-v1`, квота IP `count=3`,
+   state пуст; в выводе — 5 предупреждений.
+8. **Найден и исправлен баг регистра UUID внутри JSON** (коммит `621280a`, релиз `2.0.23`): первый `apply`
+   после заморозки падал на `required params mismatch … startupConfiguration` (`2c37fed1-…` в плане против
+   `2C37FED1-…` в живом инстансе). Проведён аудит 8 мест (см. §10 в `terraform_case_sensitivity_fix.md`),
+   добавлены `jsonutil.LowercaseUUIDsInText` и нормализация строк внутри JSON, `JsonNormalize()` приводит
+   UUID-подстроки к lowercase; покрыто тестами (`jsonutil_test.go`, `params_compare_test.go`), `go test ./...` зелёный.
+9. **Документация**: страница `docs/30_registry/guides/provider-behavior.md`, обновлённый §10 в
+   `terraform_case_sensitivity_fix.md`, записи в `NOTES`/`HISTORY`, память репозитория.
+
+## 2. Текущее состояние (на момент записи)
+
+- `DEV_STAND/FullPipe`: **`terraform state list` пуст** (после проверочного `destroy`).
+- В облаке: кластер `shturval-dev-00` — `suspended`; vDC — `suspended`; эдж — `running`
+  (`ipSpaceName = internet-ipv4-v1`, SNAT включён); квота IP организации — `count = 3`.
+- Кластер «спит»: `.146:6443` TCP принимается эджем, но k8s не отвечает (`connection reset by peer`);
+  `.148:443` открыт (эдж/AVI живут).
+- Версия провайдера: в реестре dev — **`2.0.23`**; пины `versions.tf` в `DEV_STAND/FullPipe` и
+  `DEV_STAND/FPipeGmail` — `2.0.23`.
+- Новый (не проверенный вживую) стенд пользователя: `DEV_STAND/FPipeGmail/`.
+
+## 3. Что делать дальше
+
+1. **Проверить обратный ход** (запускает только пользователь): `terraform apply` в `DEV_STAND/FullPipe`.
+   Ожидание: `adopt` по имени + `resume` для кластера и vDC; эдж/SNAT/квота — no-op; затем `plan` = `No changes`.
+   Проверки: `terraform state list`, `terraform state show`, статусы инстансов в API ЛК, `kubectl get nodes`
+   (снова Ready), поды `44/48` (+ мусор `shturval-init-job`, уйдёт сам).
+2. **Доку при необходимости**: добавить страницу `provider-behavior.md` в `nav` (`mkdocs.yml`) и запустить
+   `TOOLS/scripts/04_build_and_publish_docs.sh` — **не запускать без прямой команды**.
+3. **Открытые техдолги:**
+   - ref-параметр внутри JSON **не валидируется** при adopt (`resources_core/ref_validation.go`);
+   - регистр ключей в `lookupLiveParam` (`core/operation_run.go`, `operation_run_bycode.go`) — требует живой проверки;
+   - тикет в платформу: TTL/очистка Failed-подов установщика + порядок установки компонентов до готовности Cilium;
+   - тикет в платформу: у Эджа нет операции `suspend` (в `availableOperations` только `delete/modify/reconcile`).
+4. **Полный teardown** — осознанно: `keep_on_destroy = false` и `suspend_on_destroy = false`, порядок
+   кластер → `count=0` → SNAT → эдж → vDC (для vDC действует правило «14 дней после suspend»).
+
+## 4. Шпаргалка: режимы destroy
+
+| Ресурс | Флаг | Поведение при destroy | Предупреждение |
+|---|---|---|---|
+| `nubes_k8s_sthutrval_cluster` | `suspend_on_destroy = true` | `suspend` | «Ресурс заморожен, а не удалён» |
+| `nubes_vc_vdc` | `suspend_on_destroy = true` | `suspend` | то же |
+| `nubes_vc_nsxt` (эдж) | `keep_on_destroy = true` | не трогается | «Ресурс оставлен как есть, а не удалён» |
+| `nubes_vc_nsxt_snat` | `keep_on_destroy = true` | не трогается | «SNAT не выключался» |
+| `nubes_vc_org_ip_allocation` | `keep_on_destroy = true` | не трогается | «Аллокация IP не снималась» |
+
+Приоритет: `keep_on_destroy` > `suspend_on_destroy` > обычное удаление. Дефолты провайдера — разрушающие;
+«заморозка» включается в `.tf` стенда.
+
+## 5. Факты платформы (проверено)
+
+- 1 кластер Штурвала = 1 vDC; vDC удаляется только через 14 дней после `suspend`.
+- Квоту IP нельзя опустить ниже занятых адресов; адреса кластера `suspend` не освобождает.
+- У эджа нет `suspend`; удаление эджа при живых зависимых (vApp/VM/кластер) недопустимо.
+- API ЛК: `GET /api/v1/svc/instances/{uid}`, состояние — `instance.state.params`, статус — `explainedStatus`,
+  операции — `availableOperations`; ошибки операции — в теле (`isSuccessful=false`, `errorLog`), HTTP 200/201.
+- Обязательные заголовки API ЛК: браузерный `User-Agent`, `Referer: https://deck-dev.ngcloud.ru/`,
+  `Authorization: Bearer <secrets/narodDEV.token>` — иначе `403`.
+- Регистр UUID: облако отдаёт один и тот же UUID в разных регистрах → сравнивать всегда без учёта регистра
+  (в т.ч. **внутри JSON**).
+
+## 6. Релизы
+
+- Схема: prod `1.*`, dev `2.*`, test `3.*`; актуальная dev — `2.0.23` (`VERSIONS.md`).
+- Релиз: `TOOLS/scripts/03_build_and_upload_provider.sh --profile TOOLS/config/dev <версия>`
+  (сам прогоняет `01` + `02`, собирает, подписывает, заливает, обновить `VERSIONS.md` вручную).
+- Локальная проверка без релиза: `go build -o TMP/devbin/terraform-provider-nubes .` в `provider/`
+  и `TF_CLI_CONFIG_FILE=TMP/terraformrc.dev terraform validate|plan` (dev_overrides).
+- YAML-спеки (`generated/*/resources_yaml/`) **не редактировать руками** — `01_generate_yamls.sh` перезапишет их из API.
+
+## 7. Правила работы (для нового чата)
+
+- `terraform apply` / `destroy` — только пользователь. Мне доступны `init/plan/validate/show/state show`.
+- Никаких правок, коммитов, релизов и публикаций без прямой команды; после каждой правки — коммит.
+- Перед правками важных файлов — бэкап в `TMP/backup_<дата>/`.
+- Не «улучшать» соседние стенды/сервисы без команды (scope creep запрещён).
+
+## 8. Быстрые команды
+
+```bash
+# состояние стенда
+cd DEV_STAND/FullPipe && terraform state list && terraform plan
+terraform state show nubes_k8s_sthutrval_cluster.shturval | grep -E "id|adopt|suspend|keep"
+
+# кластер
+kubectl get nodes
+kubectl get pods -A --no-headers | awk '{split($3,a,"/"); tot++; if($4=="Running"&&a[1]==a[2]) ok++} END{print tot, ok}'
+kubectl get pods -A | grep -v -E "Running|Completed"
+
+# API ЛК (dev)
+TOK=$(tr -d '\n' < secrets/narodDEV.token)
+curl -s -H "Authorization: Bearer $TOK" \
+     -H "User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36" \
+     -H "Referer: https://deck-dev.ngcloud.ru/" \
+     'https://lk-api-gateway-dev.ngcloud.ru/api/v1/svc/instances/94627ff4-33a5-48f2-aca1-695741e0b6a2'
+
+# реестр провайдера (dev)
+curl -s https://tf-registry.containerk8s.services.ngcloud.ru/v1/providers/nubes-dev/nubes/versions
+```
@@ -5,7 +5,7 @@
 | Стенд | Namespace | Версия | Дата заливки |
 |---|---|---|---|
 | PROD | `nubes` | `1.0.0` | 2026-09-03 | (новая нумерация) |
-| DEV | `nubes-dev` | `2.0.22` | 2026-09-24 | (feat: третий режим destroy `keep_on_destroy` = state_only для всех instance-ресурсов (в т.ч. Эдж, у которого нет suspend) + предупреждения «заморожен/оставлен как есть» в `Delete`; реализовано универсально в генераторе) |
+| DEV | `nubes-dev` | `2.0.23` | 2026-09-24 | (fix: UUID внутри JSON нормализуется к lowercase при сравнении (adopt suspended-инстанса падал на регистре `nsxtUid`) + `JsonNormalize` приводит UUID-подстроки; тесты) |
 | TEST | `nubes-test` | `3.0.0` | 2026-09-03 | (новая нумерация) |

 ## Как проверить
@@ -0,0 +1,206 @@
+# Как работает провайдер Nubes: поведение и отличия от канонического Terraform
+
+> Страница для тех, кто уже работал с Terraform и хочет понять, чего ожидать от провайдера Nubes,
+> и для DevOps, которым важно знать, что реально произойдёт в облаке при `plan`, `apply` и `destroy`.
+> Здесь описан наблюдаемый контракт (что уже проверено на живых стендах) и ограничения платформы.
+
+## 1. Суть в одном абзаце
+
+Провайдер Nubes — это не плагин к гипервизору, а **обёртка над API личного кабинета**: каждый Terraform-ресурс
+соответствует *инстансу услуги* в облаке, а `create` / `update` / `delete` транслируются в **асинхронные операции**
+платформы (`create`, `modify`, `suspend`, `resume`, `delete`). Отсюда и все отличия от привычного Terraform:
+
+- операции **долгие** — провайдер ждёт их завершения (поллинг);
+- меняется **уже созданный объект**, а не создаётся заново;
+- ошибки приходят **внутри тела ответа**, а не HTTP-кодом;
+- ресурс ищется **по имени**, а не только по `id`;
+- удаление может быть **«мягким»** — объект остаётся в облаке.
+
+## 2. Какие ресурсы за что отвечают
+
+| Услуга облака | Ресурс Terraform | Что делает |
+|---|---|---|
+| Организация в Cloud Director (19) | `nubes_vc_org_ip_allocation` | **модификатор**: меняет квоту внешних IP в организации (саму организацию создают в ЛК, Terraform её не трогает) |
+| Виртуальный датацентр (21) | `nubes_vc_vdc` | создаёт vDC с ресурсами (CPU/RAM/Storage) |
+| Сетевой шлюз периметра (22) | `nubes_vc_nsxt` | создаёт Edge (routed-сеть, ALB/AVI) |
+| Сетевой шлюз периметра (22) | `nubes_vc_nsxt_snat` | **модификатор**: включает/переключает SNAT (`ipSpaceName`) на существующем Edge |
+| Kubernetes кластер Штурвал (150) | `nubes_k8s_sthutrval_cluster` | создаёт кластер (control plane + группы воркеров) |
+
+Общее правило. Ресурс, у которого есть свой «объект в облаке», **создаёт** этот объект. А то, что платформа
+меняет операцией `modify` (квота IP, включение SNAT, настройки шлюза), собрано в отдельные ресурсы-
+**модификаторы**: они не создают ничего нового, а правят уже существующий объект.
+
+## 3. Отличия от «учебного» Terraform
+
+| Ожидание по канону | Как в Nubes | Причина |
+|---|---|---|
+| `create` = один вызов API | Создание инстанса — **последовательность**: `POST /instances` → `POST /instanceOperations` → параметры (`instanceOperationCfsParams`) → `run` → поллинг до `dtFinish` | Так устроен API платформы |
+| `id` — произвольная строка | `id` = UUID инстанса в облаке; провайдер читает его из ответа платформы | Состояние живёт в облаке, не в Terraform |
+| `update` = замена при несовместимых параметрах | `update` = операция **`modify`** над тем же инстансом; часть параметров — **create-only** (менять нельзя → ошибка на этапе plan) | Платформа не пересоздаёт объекты «из коробки» |
+| есть `data sources` для поиска существующего | Поиск/ссылки — через **ref-параметры**: можно указать UUID **или имя** инстанса | Экономит data sources, но требует дисциплины в значениях |
+| `import` — явная команда | Плюс к `import` есть **авто-усыновление** `adopt_existing_on_create = true`: ресурс сам находит инстанс **по имени** | В проде объекты живут неделями, и пересоздавать их нельзя |
+| `plan` показывает, что ресурс уже существует | **Нет**: проверка «инстанс с таким именем уже есть / adopt» выполняется в `Create`, то есть на `apply` | Иначе ломается `destroy` и работа с tainted-ресурсами |
+| `delete` удаляет | `delete` может быть `delete` / `suspend` / `state_only` — см. §5 | У платформы не всё удаляется, а часть объектов удалять нельзя, пока жив потребитель |
+| ошибка приходит HTTP-кодом | Ошибка операции — **в теле**: `isSuccessful=false` + `errorLog`, при успешном HTTP-коде | API платформы отвечает 200/201 почти всегда |
+| операции быстрые | Операции асинхронные и долгие (Штурвал — десятки минут) → параметр `operation_timeout`; одновременные операции на одном инстансе не поддерживаются | Наследство платформы (внутри — CFS-оркестратор) |
+| план обязан совпадать с config | Тоже, но: **ref-параметры в плане остаются как написаны** (`name` не подменяется на `uuid`), а уже перед вызовом API провайдер сам разберётся, имя это или UUID | Иначе Terraform упадёт с «Provider produced invalid plan» |
+| параметры сравниваются как строки | JSON-параметры сравниваются **канонично**: порядок ключей и пробелы не важны, скаляры приводятся к строке, UUID — без учёта регистра | API возвращает JSON в своём виде, иначе будет «вечный diff» |
+| идентичность — по `id` | Дополнительно: инстанс ищется по `resource_name` (displayName) → **переименование = новый ресурс** | Имя задаётся при создании и не меняется |
+
+### Что из этого следует на практике
+
+- `terraform plan` **не может** проверить, что «такой объект уже есть»: он это покажет как `will be created`,
+  а разбираться будет `apply`.
+- `terraform apply` на существующей инфраструктуре — это нормальный сценарий (adopt), если включён
+  `adopt_existing_on_create`; без флага вы получите явную ошибку-конфликт, а не дубль ресурса.
+- Долгие операции требуют терпения: смотрите `operation_timeout`, не запускайте вторую операцию по тому же объекту.
+
+## 4. Создание, чтение, изменение, удаление
+
+**Создание.** Провайдер формирует параметры операции, отправляет её и ждёт завершения. Параметры, зависящие
+от других ресурсов (например `vdc_uid`, `nsxt_uid`), передаются как ref-значения: UUID или имя.
+
+**Чтение (refresh).** Значения `state_params` / `state_out` приходят из облака: так в state попадают
+адреса (`kubernetesApiAddress`, `ingressAddress`), имена, текущие параметры.
+
+**Изменение.** Если параметры поменялись, вызывается `modify` (для модификаторов — обратный `modify` при удалении).
+Параметры, помеченные как create-only, изменить нельзя — провайдер скажет об этом до обращения к API.
+
+**Удаление.** См. следующий раздел — это самое неочевидное место.
+
+## 5. Удаление: `delete`, `suspend` и «оставить как есть»
+
+У платформы три разных исхода, и провайдер умеет все три. Управляется флагами:
+
+| Флаг | Где применим | Поведение при `destroy` | Предупреждение в выводе |
+|---|---|---|---|
+| `suspend_on_destroy = true` | кластер Штурвала, vDC (по умолчанию `true`) | объект **приостанавливается**, не удаляется | «Ресурс заморожен, а не удалён» |
+| `keep_on_destroy = true` | Edge, SNAT, квота IP (по умолчанию `false`) | объект **не трогается в облаке**, только убирается из state | «Оставлен как есть» (для SNAT — «SNAT не выключался», для квоты IP — «Аллокация IP не снималась») |
+| оба `false` | любой | обычное удаление | — |
+
+Если выставлены оба флага, победит `keep_on_destroy` (объект просто не тронут). По умолчанию провайдер
+удаляет по-настоящему (`keep_on_destroy = false`), а «заморозку» или «оставить как есть» включают явно
+в конфигурации стенда.
+
+### Почему Edge остаётся `running`
+
+Edge **физически не умеет `suspend`**: в списке доступных операций шлюза есть только `delete`, `modify`,
+`reconcile`. Усыпить его платформа не даёт, поэтому единственный корректный способ «не удалять шлюз» —
+не трогать его: `keep_on_destroy = true`. Побочный эффект — шлюз продолжает работать и тарифицироваться,
+и через него продолжают публиковаться внешние адреса (API кластера и ingress). Именно поэтому удаление Edge
+при живом кластере Штурвала (или других зависимых объектах: vApp, VM) считается недопустимым.
+
+### Почему SNAT остаётся включённым, а квота IP не обнуляется
+
+- SNAT-модификатор с `keep_on_destroy = true` **не отправляет** обратный `modify` с `ipSpaceName = "no-needed"`,
+  то есть SNAT для виртуальных машин остаётся в прежнем состоянии.
+- Квота внешних IP: уменьшать `count` **ниже фактически занятых адресов платформа не разрешает**
+  (ошибка вида «Кол-во занятых Ip … Невозможно выставить параметр count ниже этого параметра»).
+  Адреса держит кластер Штурвала (API + ingress), и `suspend` кластера их **не освобождает**.
+  Поэтому при «заморозке» квота не изменяется вовсе, а реальное освобождение адресов возможно только после
+  удаления кластера — отдельным шагом.
+
+### Почему кластер и vDC уходят в `suspend`
+
+Для них `suspend` поддерживается платформой, и это самый близкий к «выключить» вариант: ВМ останавливаются,
+объекты не удаляются, адреса и конфигурация сохраняются. Обратный ход делает `apply`:
+
+| Что | При `destroy` (заморозка) | При следующем `apply` |
+|---|---|---|
+| Кластер Штурвала | `suspend` | adopt по имени + `resume` |
+| vDC | `suspend` | adopt по имени + `resume` |
+| Edge | не трогается (`running`) | adopt (инстанс уже работает) |
+| SNAT | не трогается (включён) | повторный `modify` теми же значениями (фактически no-op) |
+| Квота IP | не трогается | `modify` с тем же `count` (no-op) |
+
+Итого цикл «`destroy` → `apply`» на стенде выглядит как «усыпить → разбудить», а не «снести → поднять заново».
+Полностью удалить такой стенд можно только явным отказом от заморозки (`keep_on_destroy = false` /
+`suspend_on_destroy = false`) и в правильном порядке (см. §6).
+
+## 6. Конкретный пайплайн стенда: vDC → Edge → внешние IP → SNAT → Штурвал
+
+Порядок создания и зависимости:
+
+1. Организация — **вручную в ЛК** (Terraform её не создаёт).
+2. `nubes_vc_vdc` — виртуальный датацентр.
+3. `nubes_vc_nsxt` — Edge. Обязательно включать балансировщик (параметр `need_enable_avi = true`)
+   и задать не меньше 3 виртуальных сервисов (`virtual_services_count >= 3`) — это нужно кластеру Штурвала.
+4. `nubes_vc_org_ip_allocation` — внешние адреса в организации (минимум 3 по инструкции услуги Штурвала).
+5. `nubes_vc_nsxt_snat` — SNAT на Edge (по `depends_on` после аллокации адресов).
+6. `nubes_k8s_sthutrval_cluster` — кластер Штурвала (по `depends_on` после SNAT: нодам нужен выход в интернет).
+
+При удалении Terraform идёт в обратном порядке. Ограничения платформы, которые встречаются на этом пути:
+
+- **1 кластер Штурвала = 1 vDC** (действующее ограничение услуги).
+- vDC удаляется только **через 14 дней после `suspend`**; при живых Edge/vApp/VM/кластере — через поддержку.
+- Edge не удаляется при живых зависимых объектах (по инструкции услуги).
+- Квота IP не опускается ниже занятых адресов (см. §5).
+
+Как проверить, что конфигурация корректна: `terraform plan` после `apply` должен говорить
+`No changes`. Если появляется стабильный diff — сверяйте его с `terraform state show` и с тем,
+что реально показывается в личном кабинете.
+
+## 7. Регистр UUID и канонизация значений
+
+UUID в облаке не имеет «правильного» регистра: один и тот же идентификатор может прийти как `2c37fed1-…`
+и как `2C37FED1-…`. Поэтому провайдер сравнивает UUID **без учёта регистра** — в том числе внутри JSON-параметров
+(например, `startupConfiguration` кластера Штурвала). Подробный разбор проблемы и всех мест, где она может
+проявиться, — в `60_strategy/terraform_case_sensitivity_fix.md` (внутренний документ).
+
+Для JSON-параметров сравнение также игнорирует порядок ключей и пробелы, а скаляры приводит к строковому виду —
+это нужно, чтобы `plan` не показывал «изменение» там, где API вернул то же значение в другом формате.
+
+## 8. Чек-лист DevOps
+
+- Пин версии провайдера привязан к стенду: **prod `1.*`, dev `2.*`, test `3.*`**; после смены версии —
+  `terraform init -upgrade`.
+- Перед `apply` и после — смотрите `plan`; ожидаемый финальный результат — `No changes`.
+- **Читайте предупреждения `destroy`**: «заморожен», «оставлен как есть», «SNAT не выключался» — это не косметика,
+  а отчёт о том, что объекты продолжают жить и тарифицироваться.
+- Не удаляйте объекты стенда руками в ЛК между `destroy` и `apply`: авто-усыновление ищет их по имени, и на удалённом
+  объекте упрётся в состояние `not created`.
+- Долгие операции: задавайте `operation_timeout` (для Штурвала — `60m`), не запускайте параллельные операции
+  по одному объекту.
+- Проверяя состояние через API ЛК, помните про обязательные заголовки (браузерный `User-Agent` и `Referer`) —
+  иначе отдаёт `403`.
+
+## 9. FAQ
+
+**Почему `plan` пишет `will be created`, если объект уже есть?**
+Потому что проверка существования и усыновление выполняются на `apply` (в `Create`). В state ресурса нет → план
+честно планирует создание. Решение — `adopt_existing_on_create = true`.
+
+**Почему `destroy` сказал `5 destroyed`, а в облаке всё живо?**
+Сработала «заморозка»: кластер и vDC приостановлены, Edge, SNAT и квота IP не изменялись. Terraform «удалил»
+ресурсы только из своего состояния. Смотрите предупреждения в выводе.
+
+**Почему IP не освободились?**
+Квота не может стать меньше числа занятых адресов, а их держит кластер. Пока кластер существует (даже в `suspend`),
+платформа не даст уменьшить `count`.
+
+**Почему Edge нельзя приостановить?**
+У платформы для шлюза нет операции `suspend` — только `delete`, `modify`, `reconcile`.
+
+**Почему после `apply` кластер ожил сам?**
+Сработало усыновление: ресурс нашёл инстанс по имени (`adopt_existing_on_create`), увидел статус `suspended`
+и выполнил `resume`.
+
+**State пуст, а объекты в облаке есть. Что делать?**
+Это ожидаемый результат «заморозки». `terraform apply` в том же каталоге усыновит объекты обратно.
+
+**Кто-то удалил объект в ЛК. Что будет?**
+Усыновление не найдёт его и провайдер завершится ошибкой с указанием статуса (`not created`) — нужно либо создать
+объект заново, либо разбираться с конфигурацией.
+
+**А можно всё-таки удалить стенд полностью?**
+Да, но осознанно: выставить `keep_on_destroy = false` и `suspend_on_destroy = false`, затем удалять в порядке
+кластер → квота IP → SNAT → Edge → vDC, при необходимости — через поддержку (для vDC действует правило 14 дней).
+
+## 10. Куда смотреть дальше
+
+- `curated/pipeline/vdc_edge_ip_snat.md` — пошаговый разбор цепочки vDC → Edge → IP → SNAT.
+- `curated/modifiers/org_ip_and_snat.md` — ресурсы-модификаторы.
+- `30_registry/guides/terraform-structure.md` — структура манифестов.
+- Внутренние документы (не публикуются): `60_strategy/provider_philosophy.md`,
+  `60_strategy/modifier_resources_ideology_and_specification.md`,
+  `60_strategy/adopt_ref_validation.md`, `60_strategy/terraform_case_sensitivity_fix.md`.
@@ -239,5 +239,59 @@ gr.NeedsStringsImport = hasRestoreCasingParams(gr.SchemaParams) || analyzeNeedsS

 ## 9. Версия

-Фикс введён в версии провайдера **5.0.46**.  
+Фикс введён в версии провайдера **5.0.46** (старая линия; актуальные линии — prod `1.*`, dev `2.*`, test `3.*`, см. §10).  
 Сгенерированные ресурсы пересозданы после изменения генератора.
+
+---
+
+## 10. Обновление 2026-09-24: UUID внутри JSON (важно)
+
+**Что уточнилось.** Посылка «API всегда возвращает lowercase» **неверна**. На живом стенде (Shturval dev-00)
+один и тот же UUID приходил в разных регистрах: `vdcUid` — `d0937335-…` (lowercase), а `nsxtUid` кластера —
+`2C37FED1-…` (UPPERCASE). Значит ориентироваться на «API нормализует» нельзя: сравнивать нужно всегда
+без учёта регистра.
+
+**Где вылезло.** Первый `apply` после «заморозки» стенда упал на усыновлении приостановленного кластера:
+
+```
+Error: required params mismatch for resource_name shturval-dev: startupConfiguration
+(plan={… "nsxtUid":"2c37fed1-…" }, actual={… "nsxtUid":"2C37FED1-…" }).
+```
+
+**Почему предыдущие пять фиксов не помогли.** Они закрывали: отправку в API (`core/refsvc.go`,
+`core/refsvc_resolve.go`), сравнение **одиночных** значений (`resources_core/params_compare.go`,
+`normalizeCompareValue`), сравнение create-only атрибутов (`strings.EqualFold` в шаблоне генератора)
+и восстановление регистра в state. Ни один из них не смотрит **внутрь JSON**, а adopt приостановленного
+инстанса сравнивает параметр целиком как JSON:
+`RequiredParamsMismatch` → `paramsEquivalent` → `JSONStringsEquivalent` → `jsonutil.normalizeJSONScalarsToStrings`,
+где строки возвращались как есть (`case string: return val`). У Штурвала ref-параметры упакованы в JSON
+(`startupConfiguration`), а путь adopt-suspended задействован впервые.
+
+**Аудит: где регистр UUID может вылезти (проверено 24.09).**
+
+| # | Место | Что ломает |
+|---|---|---|
+| 1 | `resources_core/required_params_compare.go` (`paramsEquivalent` → `JSONStringsEquivalent`) | adopt приостановленного инстанса — hard error (этот кейс) |
+| 2 | `core/modifier_compare.go` | ложное «параметр изменился» → лишний `modify` на каждом apply |
+| 3 | `resources_core/state_refresh.go` (сохранение планового JSON) | в state уедет регистр API вместо значения из config |
+| 4 | `resources_core/resource_diagnostics_required.go` (create-диагностика) | та же `RequiredParamsMismatch` |
+| 5 | `resources_core/params_compare.go` (`ParamsMatchForResume`) | одиночный UUID ок, JSON — та же дыра |
+| 6 | `resources_core/json_planmodifier.go` (`JsonNormalize()`) | для JSON-атрибутов с UUID внутри — риск вечного diff |
+| 7 | `resources_core/ref_validation.go` (`ValidateRefParamsOnAdopt`) | ref-параметр, зашитый внутрь JSON, **не проверяется вообще** (открыто) |
+| 8 | `core/operation_run*.go` (`lookupLiveParam`) | подстановка live-значений по ключам: при другом регистре ключа может молча не сработать (открыто, требует живой проверки) |
+
+**Фикс (провайдер `2.0.23`, dev).**
+
+- `internal/core/jsonutil/jsonutil.go`: добавлен `LowercaseUUIDsInText` (UUID-подстрока → lowercase), и строковые
+  значения **внутри JSON** теперь нормализуются в `normalizeJSONScalarsToStrings` — закрывает пункты 1–5.
+- `internal/resources_core/json_planmodifier.go`: `JsonNormalize()` после `json.Compact` приводит UUID-подстроки
+  к lowercase (типы и порядок ключей **не** меняются — план обязан совпадать с config) — закрывает пункт 6.
+- Тесты: `internal/core/jsonutil/jsonutil_test.go`, `internal/resources_core/params_compare_test.go`
+  (в т.ч. на реальном `startupConfiguration` кластера).
+
+**Дополнение к алгоритму диагностики (§8):**
+
+7. Если расхождение — внутри JSON-параметра, проверьте именно UUID-подстроки и их регистр (не только одиночные
+   значения); смотрите `jsonutil.LowercaseUUIDsInText`.
+8. Не «лечите» это нормализацией плана целиком (скаляры → строки, сортировка ключей): для атрибутов из config
+   допустимо менять только регистр UUID-подстрок, иначе Terraform ругнётся на несоответствие плана конфигу.
Author	SHA1	Message	Date
Nail	dbaadccc50	docs(resume): подробное резюме состояния Штурвал/freeze для нового чата + стенд DEV_STAND/FPipeGmail	2026-09-25 08:05:12 +03:00
Nail	c808a3b345	docs: повышение читаемости provider-behavior.md (упрощены §1 списком, §2 модификаторы, §3 id/нормализация, §5 приоритет флагов, §6 ALB-константы)	2026-09-24 20:53:17 +03:00
Nail	aaf87d966b	docs: страница «Как работает провайдер: отличия от канонического Terraform» (freeze/destroy, пайплайн vDC→Edge→IP→SNAT→Штурвал, FAQ) + кейс UUID внутри JSON в case-sensitivity документе	2026-09-24 20:40:18 +03:00
Repinoid	10520670a5	1	2026-09-24 20:27:54 +03:00
Nail	208d97e2ce	docs+release(dev): 2.0.23 — аудит регистра UUID (8 мест), фикс внутри JSON, залито в реестр	2026-09-24 20:22:39 +03:00