chore: save current changes

docs/prompts/prompt_for_opus_iac_shturval_modify.md

@@ -27,7 +27,7 @@ k8sShturval -> create
 - Провайдер генерируется из YAML-спеков. Схема tf-ресурса строится ТОЛЬКО из операции `create`.
 - `vIPConfigure` (array-map-fixed, sub: name/count) есть только в `modify` vc_org (id 207); в `create` (136) его нет.
 - `ipSpaceName` (string) есть только в `modify` vc_nsxt (id 111); в `create` (10) его нет.
-- `vIPConfigure` — накопительный: повторный `modify` выделяет IP заново, а не задаёт состояние.
+- `vIPConfigure` — **не накопительный, а replace-семантика** (подтверждено `docs/ORG_IP_MODIFIER_TEST_2026-09-22.md`): повторный `modify` с тем же `count` не аккумулирует IP (1→1), работает в обе стороны (вверх/вниз/до 0), `count=0` принимается. Значение задаётся целиком, читается из `state.params`.
 - `ipSpaceName` выводится из цепочки `providerVdc -> providerGateway -> ipSpace`, которую пользователь не знает. Сейчас платформа «подкладывает» недостающие параметры при создании пустой орги.
 - Допущение платформы: в организации один T0/провайдер-шлюз. Рост числа T0 отложен.
 - Платформа в движении: форма ресурсов зависит от новых спеков (ждут, придут сначала в sandbox).
@@ -38,7 +38,7 @@ k8sShturval -> create
 
 ## Вопросы
 
-1. Как корректно выразить накопительный `vIPConfigure` идемпотентным tf-ресурсом (чтобы повторный apply не выделял IP заново)? Как устроить Read и Delete (inverse: обнулить count), если отдельного API-объекта нет?
+1. `vIPConfigure` уже ведёт себя как replace-состояние (идемпотентно, обе стороны, `count=0` читается из `state.params`). Как это оформить в tf-ресурсе, чтобы Read брал `state.params`, а Delete (inverse) выставлял `count=0` — если отдельного API-объекта нет?
 
 2. Как провайдер должен получать выводимое значение `ipSpaceName` (цепочка providerVdc → providerGateway → ipSpace): data-source, вычисляемое из state родителя, или иное? Где граница «данные vs логика», что хранить в реестре, что выводить из типа/state?