tf_provider/prompt_for_opus_inverse_architecture.md

Вопрос: архитектура inverse-отката модификаторов (без чтения файлов)

ЗАПРЕЩЕНО лезть в файлы репозитория. Отвечай только по тексту ниже. Ответ — максимально краткий (тезисы), но исчерпывающий.

Контекст

Terraform provider для Nubes Cloud. Есть «модификаторы» — отдельные TF-ресурсы, вызывающие операцию modify над инстансом по кодам параметров, а не по числовым id. Примеры:

• vc_org → модификатор ip_space, параметр vIPConfigure (array-map-fixed) = [{"name":"internet-ipv4-v1","count":3}] — выделение внешних IP.
• vc_nsxt → модификатор network, параметры needEnableAVI (boolean), ipSpaceName (string, valueList содержит sentinel "no-needed"), routedNetConfiguration.

У модификатора есть delete_strategy, определяющий что делать при terraform destroy:

• noop_warn — снять из state, эффект остаётся (предупреждение).
• error — запрет удаления (сейчас так на vc_org, из-за чего destroy встаёт).
• inverse — при Delete выполнить обратную операцию modify с delete_params (список {Code, Value}).

Проблема

Хочу, чтобы destroy и apply были полными и симметричными. При удалении модификатора нужно «откатить» эффект:

1. needEnableAVI → false.
2. ipSpaceName → "no-needed".
3. vIPConfigure → count=0, имя сохранить ([{"name":"internet-ipv4-v1","count":0}]).

Пункты 1-2 — статические константы, текущий механизм delete_params {Code,Value} покрывает. Пункт 3 — динамический: имя берётся из текущего state инстанса, обнуляется только count.

Требование: решение должно быть архитектурно чистым и универсальным (привязанным к типам данных из API, dataType/valueList/sub_params), а не хардкодом имён сервисов — чтобы при неглобальных изменениях API перегенерация подхватывала.

Ключевые факты (уже проверены)

• count=0 принимается API, несмотря на minvalue:1/integer > 0 в схеме. Идемпотентно.
• ipSpaceName sentinel «выключен» = "no-needed" (есть в valueList).
• needEnableAVI — boolean: обратное = "false".
• Типы из API: needEnableAVI=boolean; ipSpaceName=string(+valueList); vIPConfigure=array-map-fixed (sub_params: name=string, count=integer).

Вопросы (нужны краткие ответы)

1. Как правильно расширить модель delete_params, чтобы поддержать и статичные обратные значения (false, no-needed), и динамические преобразования (count→0)? Оцени вариант «типизированные правила: Mode∈ {static, zero_count, …}, где static=текущий Value, zero_count=обнулить integer-полеcount` в каждом элементе array-map-fixed, взятом из live state.

2. Универсальнее ли выводить обратные значения ИЗ ТИПА ПАРАМЕТРА (boolean→"false", string+valueList→первый/помеченный sentinel, array-map-fixed→нулевой count в integer-полях), чем задавать их в реестре исключений? Где баланс: что держать в реестре (данные), что выводить из типа (логика)?

3. Нужен ли отдельный маркер «какое поле array-map-fixed обнулять» (сейчас это count), или достаточно общего правила «обнулить все integer-поля sub_params»? Риски обоих.

4. Правильный порядок destroy при зависимостях: edge_net (SNAT off + ALB off) → org_ips (count=0) → nsxt → vdc. Как Terraform сам выведет порядок из depends_on, и где инверсия/откат может конфликтовать с порядком удаления дочерних инстансов?

5. Есть ли подводные камни в самом inverse-delete (если дети ещё живы, откат count=0 на орге может не пройти)? Нужен ли двухфазный подход или достаточно полагаться на порядок?

Формат ответа: пункты пронумерованы под мои вопросы, 1-3 предложения на пункт. Без лишнего.