tf_provider/prompt_for_opus_modifiable_architecture.md

Задача: спроектировать ПРОСТУЮ логику «изменяемости» параметров (CreateOnly vs Modifiable)

Проблема

Генератор terraform-провайдера строит проверку «Нельзя изменить X» (CreateOnly) на основе только instance-modify. Из-за этого возникают противоречивые и сломанные ситуации:

generated/dev/resources_yaml/22_vc_nsxt.yaml:

• create (id 10), param needEnableAVI (id 340) — помечен is_modifiable: true;
• instance-modify у vc_nsxt НЕТ (modify 111 — это modifier vc_nsxt.network).

Генератор:

ComputeCreateOnly(createParams, instanceModifyParams):
  поле считается CreateOnly, если его code нет в instance-modify

Следствие: needEnableAVI попадает в CreateOnly → генерится жёсткая проверка «Нельзя изменить need_enable_avi», хотя по YAML параметр is_modifiable: true.

Плюс ConvertParams вообще не переносит is_modifiable из ParamSpec в Param — поле теряется, логика его учесть не может.

Ключевые файлы (текущая логика)

• TOOLS/lib/types.go — ParamSpec.IsModifiable (есть, is_modifiable сериализуется в YAML)
• TOOLS/resource-generator/internal/types/types.go — Param (НЕТ поля IsModifiable)
• TOOLS/resource-generator/internal/loader/loader.go — ConvertParams (не переносит IsModifiable)
• TOOLS/resource-generator/internal/params/params.go — ComputeCreateOnly (игнорирует is_modifiable и modifier)
• TOOLS/resource-generator/internal/templates/instance.go — шаблон, рендерит «Нельзя изменить» из .CreateOnlyParams
• YAML: generated/dev/resources_yaml/22_vc_nsxt.yaml (modify 111 — kind: modifier)

Существующие понятия операции

В YAML операции бывают видов:

• kind: instance (create / modify / suspend / resume / delete)
• kind: modifier (отдельный TF-ресурс, modify на родительском инстансе, например vc_nsxt.network)
• kind: subresource
• kind: action

Цель

Спроектировать единую, простую и понятную модель «изменяемости» параметра, чтобы:

1. параметр считался изменяемым, если он изменяем ХОТЯ БЫ через один канал (instance-modify ИЛИ modifier);
2. «Нельзя изменить» генерировалось ТОЛЬКО для реально create-only параметров;
3. is_modifiable из YAML был единственным источником правды (или явно согласован с каналами modify);
4. не было противоречий вида «в YAML is_modifiable:true, а в коде «Нельзя изменить»».

Вопросы к Opus

1. Какая каноническая модель: вычислять изменяемость по is_modifiable (флаг из YAML), по наличию кода в любом modify (instance + modifier), или по комбинации?
2. Где именно проставлять/вычислять флаг — в yaml-generator (при генерации YAML), или в resource-generator (при генерации Go)?
3. Как связать modifier-параметры (vc_nsxt.network) с parent-инстансом (vc_nsxt), чтобы instance знал, что needEnableAVI изменяется через modifier?
4. Минимальный, без legacy-наслоений, набор правил.

Ответ — кратко, с конкретной архитектурой и точками правки (файл + функция).