tf_provider/prompt_for_opus_modifier_plan_review.md

Ревью плана реализации: редизайн модификаторов

Прошу отревьюить план PLAN_modifier_redesign.md (10 шагов). Это проект к реализации, не код. Вызовись: найди дыры, пропущенные кейсы, ошибки в порядке шагов, нестыковки.

Контекст решения (уже согласовано, НЕ пересматривать)

• Модификатор = декларативная проекция полей родителя, единый reconcile() (Create≡Update).
• Полный payload (не дельта), досылка: задан→значение, иначе live→default→skip.
• delete_strategy: noop_warn | inverse | error (дефолт noop_warn), idempotency: none | check_before_run.
• Pre-check desired==current в core (не в resources_core, не в шаблоне), по живому state_params.
• is_modifiable — единственный сигнал изменяемости (фикс CreateOnly уже есть).

Ключевые файлы-факты (сверены с кодом)

• TOOLS/lib/types.go — OperationSpec/ParamSpec (алиасы в обоих генераторах).
• TOOLS/yaml-generator/main.go — serviceSpecificModifiers (реестр исключений, источник канона).
• TOOLS/resource-generator/internal/loader/loader.go — ветка kind==modifier, ValidateSpec.
• TOOLS/resource-generator/internal/templates/modifier.go — шаблон.
• provider/internal/resources_core/crud.go — RunOperationByCodeWithTimeout.
• provider/internal/resources_core/json_normalize.go — JSONStringsEquivalent (импорт в core = цикл).
• provider/internal/core/operation_run_bycode.go — клиентский запуск.

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

1. Порядок шагов 1–10 корректен? Где есть скрытая зависимость, которую я пропустил?
2. Шаг 5 (вынос JSON-эквивалентности в core/jsonutil) — правильный путь снять цикл импорта, или есть чище (напр. оставить JSONStringsEquivalent в resources_core и передавать нормализованные строки в core уже готовыми)?
3. Шаг 6 — сигнатура modifierDesiredEqualsCurrent(desired map[string]string, cfsParams []universalCfsParam) bool корректна? Хватает ли данных для сравнения всех типов (bool/int/string/map-fixed/array-map-fixed)?
4. Шаг 4.4 Delete=inverse — как именно слать modify: delete_params + досылка live остальных (полный payload) — это правильно, или есть подводный камень?
5. Шаг 8 — расширение реестра serviceSpecificModifiers до структуры: верный источник? Или delete_strategy/idempotency правильнее держать отдельным реестром (не трогая тип map)?
6. Пропущен ли какой-то кейс из 16 (13 + taint/replace/partial/unknown)?
7. Есть ли риск сломать instance-ресурсы (не модификаторы) любым из шагов 1–8?

Ответ — тезисно, с указанием конкретного шага и что в нём поправить.