docs(plans): §11 — ответы Opus раунд 3 (критерий отбора = явный список в конфиге генератора, релиз A только (б), Deprecated вместо падения)

NOTES/10_plans/PLAN_IAC_MODIFY_RESOURCES_2026-09-24.md

@@ -83,6 +83,10 @@ nubes_vc_nsxt  →  nubes_vc_org_ip_allocation  →  nubes_vc_nsxt_snat  →  k8
 > ⚠️ По ревью Opus (2026-09-24) пункт **§7б — обязательное условие**, а не опциональное:
 > без исключения modify-only из create-read-back при переходном варианте будет борьба за поле
 > между instance-ресурсом и модификатором. Пункт остаётся обязательным follow-up.
+>
+> 📌 Раунд 3: §7б выделяется в **отдельный релиз A** (универсально, схема не меняется, non-breaking,
+> полностью закрывает инцидент `inconsistent result` на create vc_org). Пункты §7а + §7в — **релиз B**
+> вместе с новыми ресурсами.
 
 ## 8. Вопросы для ревью Opus
 
@@ -150,3 +154,31 @@ nubes_vc_nsxt  →  nubes_vc_org_ip_allocation  →  nubes_vc_nsxt_snat  →  k8
    ли drift у тех, у кого поле было обязательным и уже заполнено?
 5. **Порядок релиза.** Правильно ли разводить: релиз A — только (б) (чинит create орги, ничего больше
    не трогает), релиз B — (а)+(в) вместе с новыми ресурсами-модификаторами?
+
+---
+
+## 11. Ответы Opus (раунд 3)
+
+1. **Критерий отбора.** Структурный признак «modify-only = есть в `modifyParams`, нет в `createParams`»
+   (симметрично `ComputeCreateOnly`) — факт спеки, но он ловит **все 5** сервисов и не отличает
+   «управляется модификатором» от «рабочий Update-атрибут». «Required только в modify» неполон
+   (пропускает `ipSpaceName`, `required:false`). **Автопризнака не существует — это доменное знание.**
+   `owned_by_modifier: true` в пер-сервисном YAML — отвергнуть (нарушает канон);
+   правильно — **явный список в конфиге генератора**.
+2. **Безопасность (б): безопасно для всех 5.** Read-back в create кладёт в state пост-create дефолт
+   (`[{}]`), которого юзер не задавал — это и есть источник `inconsistent result`. Create их и так не шлёт.
+   **Steady-state Read и Update read-back их по-прежнему перечитывают**, поэтому дрейф не теряется;
+   (б) убирает только бессмысленную перезапись сразу после create. s3/postgres/zones не страдают.
+3. **Существующие конфиги.** Жёстко падать нельзя (схема общая, «владелец» — доменное знание, сломает state).
+   Правильно — `Deprecated` с текстом «управляется ресурсом `…ip_allocation`» → warning на каждом plan.
+   Молчаливое прекращение отправки — плохой UX, не делать. Удаление атрибута — только в следующий major.
+4. **Снятие Required.** Затрагивает только `vIPConfigure` (`ipSpaceName` уже Optional).
+   `Optional+Computed` — штатный безопасный переход; `UseStateForUnknown` гасит unknown и drift не создаёт;
+   у заполненных полей значение удержится через read-back. Борьба за поле снимается (б)+(в).
+5. **Порядок релиза — подтверждён:**
+   - **A — только (б):** универсально, схема не меняется, non-breaking, **полностью закрывает** инцидент
+     `inconsistent result` на create `nubes_vc_org`; s3/postgres/zones не трогает.
+   - **B — (а)+(в) + новые ресурсы** (Deprecated на delegated-параметры, отцеп от read-back/send).
+
+**Следствие для наших решений:** критерий «кто делегируется» задаётся явным списком в конфиге генератора;
+работа разбивается на релиз A (маленький, безопасный) и релиз B (ресурсы + отцепка).