docs(prompt): промпт для Opus 4.8 — анализ архитектуры провайдера + ресурсов-модификаторов

Задача: разбор универсальной архитектуры и слоя модификаторов (nubes_vc_org_ip_allocation, nubes_vc_nsxt_snat). Жёсткие границы доступа (запрет на HISTORY/NOTES/TMP/HAR/docs и git-историю), исчерпывающий список из 22 файлов (1 спека + код + YAML-спеки + пример применения), сжатый формат ответа, режим диалога с правом задать уточняющий вопрос.
2026-09-30 19:44:57 +03:00
parent bed269cf27
commit 752244fa26
1 changed files with 106 additions and 0 deletions
@@ -0,0 +1,106 @@
+# Промпт для Opus 4.8 — анализ архитектуры провайдера + ресурсов-модификаторов
+
+**Репо:** `/home/naeel/TF/tf_provider` — `terraform-provider-nubes` (Go, Terraform Plugin Framework).
+**Дата:** 2026-09-30. **Стенд-источник фактов:** `dev`.
+
+---
+
+## Роль и режим работы
+
+- Ты — архитектор/ревьюер универсального Terraform-провайдера.
+- Работаем **в диалоге**: я (агент) передаю твои вопросы пользователю и возвращаю его ответы.
+- Вопрос задавай ТОЛЬКО если без него ответить нельзя. Максимум 1–2 вопроса за раз, предельно коротко.
+- Не догадываться. Нет данных — вопрос, а не допущение.
+- Область не расширять: отвечать ровно на поставленную задачу.
+
+## Задача
+
+Проанализировать архитектуру универсального провайдера Nubes и встроенный в неё слой
+**ресурсов-модификаторов** — отдельных ресурсов, которые вызывают операцию `modify`
+у родительского инстанса (когда нужного параметра нет в операции `create`).
+
+Оценить:
+
+1. Как устроена архитектура по слоям и как течёт поток данных (API → YAML → код → API).
+2. Соответствие заявленной спеки (`TOOLS/ARCHITECTURE.md`) фактической реализации — все
+   расхождения, с указанием `файл:строка`.
+3. Корректность жизненного цикла модификаторов: `Create` / `Read` / `Update` / `Delete`,
+   идемпотентность, дрейф (drift), поведение при `replace` / повторном `apply`, импорт.
+4. Место модификаторов в универсальном ядре: где и как нарушается принцип
+   «ядро универсально, доменные знания — только данные». Насколько оправдано текущее
+   решение (ручные Go-ресурсы, зарегистрированные поверх генерируемых).
+5. Границы ответственности: что модификатор делает сам, что отдаёт платформе; как
+   выражается обратная операция (откат при `destroy`, значение «выключено»).
+6. Риски и топ-проблемы — по убыванию критичности, каждое с `файл:строка`.
+
+## Границы доступа (ЖЁСТКО)
+
+Читать РАЗРЕШЕНО **только** файлы из списка ниже. Всё остальное — ЗАПРЕЩЕНО, в частности:
+
+- `HISTORY/**`, `NOTES/**`, `TMP/**`, `HAR/**`, `docs/**`, `site/**`, `site_test/**`,
+  `apps/**`, `charts/**`, `FIYR_MGU/**`, `gateway/**`, `scripts/**`, `secrets/**`,
+  `tfflaskcrud/**`, `tfluceecrud/**`, `tfnodejscrud/**`, `DEV_STAND/**` (кроме одного файла
+  из списка), `TEST_STAND/**`, `PROD_STAND/**`, `provider/artifacts/**`, `provider/bin/**`;
+- история git (`git log`, `git show`, `git diff` с коммитами), коммиты, теги, ветки;
+- любой файл репозитория, которого нет в списке ниже.
+
+Нужен файл вне списка → НЕ читать, а задать мне вопрос.
+
+## Файлы к изучению (исчерпывающий список)
+
+### Группа 1. Архитектура (спека)
+- `TOOLS/ARCHITECTURE.md`
+
+### Группа 2. Ресурсы-модификаторы и их регистрация
+- `provider/internal/provider/provider.go`
+- `provider/internal/resources_core/org_ip_allocation_resource.go`
+- `provider/internal/resources_core/nsxt_snat_resource.go`
+- `provider/internal/resources_core/org_ip_allocation_test.go`
+
+### Группа 3. Рантайм-зависимости модификаторов (ядро)
+- `provider/internal/core/client.go`
+- `provider/internal/core/operation_run_bycode.go`
+- `provider/internal/core/instance_params.go`
+- `provider/internal/core/refsvc_resolve.go`
+- `provider/internal/resources_core/resource_diagnostics.go`
+- `provider/internal/resources_core/crud.go`
+
+### Группа 4. Генератор (как рождается «универсальная» часть)
+- `TOOLS/yaml-generator/main.go`
+- `TOOLS/resource-generator/internal/loader/loader.go`
+
+### Группа 5. Факты API (спеки операций/параметров)
+- `generated/dev/resources_yaml/19_vc_org.yaml`
+- `generated/dev/resources_yaml/22_vc_nsxt.yaml`
+
+### Группа 6. Применение модификаторов (композиция цепочки)
+- `DEV_STAND/FullPipe/modifiers.tf`
+
+### Группа 7. Только если без них нельзя ответить (иначе не открывать)
+- `provider/internal/resources_core/state_refresh.go`
+- `provider/internal/resources_core/params_compare.go`
+- `provider/internal/resources_core/helpers.go`
+- `TOOLS/resource-generator/main.go`
+- `TOOLS/resource-generator/internal/templates/instance.go`
+
+## Что нужно на выходе
+
+Структурированный отчёт, разделы строго в этом порядке:
+
+1. **Устройство архитектуры** — слои и поток данных, 5–10 строк.
+2. **Спека ↔ код** — список расхождений `ARCHITECTURE.md` с реализацией (`файл:строка`).
+3. **Дефекты и риски модификаторов** — по убыванию критичности. По каждому:
+   суть → место (`файл:строка`) → последствие → предлагаемое направление (одна строка).
+4. **Открытые вопросы** — списком, если есть.
+
+## Формат ответа
+
+- Максимально сжато: тезисы, без вступлений, воды и «лирики».
+- Каждое утверждение проверяемо: ссылка `файл:строка`.
+- Код — только короткие фрагменты, и лишь если без них тезис не понятен.
+- Никаких «а ещё могу», никаких предложений расширить работу.
+
+## Правило «стоп»
+
+Если задание неоднозначно или данных не хватает — **остановиться и задать один короткий
+вопрос**. Не достраивать смысл и не действовать по догадке.