tf_provider/prompt_for_opus_modifier_global_architecture.md

Глобальная архитектура модификаторов: как сделать их НЕ инвазивным дополнением

ЗАПРЕЩЕНО лезть в файлы репозитория. Отвечай только по тексту. Формат: тезисы, кратко, по пунктам моего вопроса. Без лишнего.

Контекст

Terraform provider для Nubes Cloud. Цепочка кодогенерации:

1. 01_generate_yamls — идёт по API, по каждому облачному сервису тянет операции и параметры, пишет универсальный YAML (resources_yaml/<id>_<svc>.yaml).
2. 02_generate_resources — по этому YAML генерирует Go-ресурсы провайдера (<id>_<svc>_resource.go).

Обычные ресурсы (nubes_vc_nsxt, nubes_vc_vdc и т.д.) — это операции create/delete/suspend/resume/reconcile над инстансом. Их apply/destroy давно стабильны и оттестированы.

Что такое «модификатор» (доменная суть)

Некоторые операции modify сервиса — это не «изменить инстанс», а отложенный дочерний шаг цепочки, который нельзя мешать с create инстанса:

• vc_org → modify с параметром vIPConfigure=[{"name":...,"count":N}] — выделение внешних IP организации.
• vc_nsxt → modify с needEnableAVI, ipSpaceName, routedNetConfiguration — настройка ALB/SNAT уже созданного Edge.

Такой modify семантически НЕ принадлежит lifecycle самого инстанса: это отдельный TF-ресурс, который должен создаваться/удаляться независимо от create/delete родителя.

Проблема (как сделано сейчас — неправильно)

Сейчас «модификаторность» вплетена в универсальную генерацию:

• реестр serviceSpecificModifiers зашит в исходник yaml-generator и помечает операцию modify как kind: modifier + пишет в YAML delete_strategy, delete_params и т.п.
• Это ломает главный принцип: YAML должен быть чистой универсальной выгрузкой из API, а обычные ресурсы — не зависеть ни от какого реестра.

Требования:

1. YAML — универсальная выгрузка ВСЕГО из API, без доменных меток (kind: modifier, delete_strategy).
2. Ресурсы облачных сервисов НЕ должны зависеть от модификаторов. Если модификаторов нет — поведение идентично прежнему (до их внедрения).
3. Модификаторы — чистое ДОПОЛНЕНИЕ: отдельная сущность, отдельный ресурс, со своей семантикой (inverse-откат при destroy, idempotency), которая НЕ просачивается в базовую генерацию.
4. При полном destroy должен быть корректный обратный откат: ALB off, SNAT no-needed, IP count=0 — при этом симметричный apply возрождает всё.

Вопросы (ответь по пунктам)

1. Правильное место доменной семантики модификатора. Где её хранить, чтобы она была «данными-наложением», а не веткой в универсальном генераторе? Варианты: (а) отдельный конфиг-файл данных (modifiers.yaml), который второй проход накладывает на базовый YAML, порождая ОТДЕЛЬНЫЕ YAML-записи модификаторов, не трогая базовые; (б) отдельный kind в самих YAML без доменных меток; (в) иное. Обоснуй.

2. Разделение «модификатор» vs «обычный modify». Как архитектурно отделить modify-как-модификатор от modify-инстанса, НЕ меняя универсальную выгрузку? Как гарантировать, что при отсутствии модификаторов обычный modify-поток ресурса вообще не затрагивается?

3. Как структурировать inverse-откат, чтобы он был: (а) генерализуемым (по типам: boolean→"false", string+valueList→off_value sentinel, array-map-fixed→zero integer-полей), (б) идемпотентным (не дёргать run, если live уже целевое), (в) не влиял на обычные ресурсы. Нужна ли отдельная модель delete_rule у модификатора.

4. Порядок destroy при цепочке модификаторов, зависящих от обычных ресурсов и друг от друга (SNAT-модификатор → IP-модификатор → edge → vdc). Как выразить зависимость модификатора от ресурса так, чтобы Terraform сам вывел обратный порядок, не завязываясь на хрупкий depends_on?

5. Минимально-инвазивная миграция. Как перейти от текущего (модификаторы «вросли» в базовую генерацию) к целевой (модификаторы — наложение) без регресса уже стабильных обычных ресурсов? Что трогать НЕЛЬЗЯ.

Ответь кратко, по номерам, 2-4 предложения на пункт.