Баг (воспроизведён на TEST 2026-10-01): при усыновлении уже существующего
пользователя БД Create выходит по раннему return (ветка 'Подресурс уже существует'
-> State.Set -> return), оставляя Computed-атрибут password в состоянии unknown.
Terraform отказывался: 'Provider returned invalid result object after apply: the
provider still indicated an unknown value for nubes_postgres_user.crud_user_0.password'.
Исправление:
- новая функция resources_core.ResolveUserPasswordFromVault(ctx, client, instanceUID,
username, current): читает пароль из Vault родителя, иначе возвращает current,
иначе типизированный null (null для Terraform — конкретное, known значение);
- в шаблоне подресурса password инициализируется null сразу после получения
instanceUID, а перед КАЖДЫМ resp.State.Set в Create проставляется конкретным
значением — включая все ветки усыновления;
- регрессионный тест усилен: считает сохранения состояния и вызовы заполнения в
Create и падает, если хоть в одной ветке password останется unknown.
Проверено: generated/test/go/90_postgres_user_resource.go — 4 State.Set и 4
вызова заполнения; go test ./... ok; go build — чисто.
Каталог tfluceecrud был закоммичен как submodule-указатель (mode 160000) без
.gitmodules — из-за этого git считал его 'изменённым' после каждого коммита в
самом репозитории приложения и правило .gitignore:16 на него не действовало.
Теперь структура однородна: tfluceecrud, tfflaskcrud, tfnodejscrud — отдельные
репозитории, лежащие локальными клонами рядом с основным репо и не входящие в
него (все три перечислены в .gitignore, строки 16-18). Файлы на диске не тронуты.
Ветка gitlink'ов apps/iot-* не затронута — они к этой задаче не относятся.
Прежние домены (tfflask / tflucee / tfnodejs) заняты старыми инстансами:
crud-flask suspended (с зависшей операцией), crud-lucee suspended, crud-nodejs running.
Создание новых сервисов с теми же доменами платформа отвергла бы как
'domain уже используется другим инстансом'.
Домен указан без точек, поэтому A-запись создаётся автоматически в служебной
DNS-зоне ресурсной платформы.
terraform validate — Success.
- старые x.0.0 удалены физически из реестра по команде владельца, затем залиты заново
теми же номерами; sha256 всех трёх сверен с локальными сборками;
- VERSIONS.md: новые sha256 + пометка об удалении версий;
- HISTORY: зачем, что удалено, схема залитой сборки (password — новый выход у
postgres_user/kafka_user/clickhouse_user/mongodb_user; у mariadb_user и pgadmin
это прежние входные параметры), проверка стенда, состояние state.
output pg_password = nubes_postgres_user.crud_user_0.password — значение известно в том
же apply, где создан пользователь, поэтому ни try(), ни двух apply в pg/ больше не
требуется. Обновлён комментарий про порядок вычисления.
Проблема: у части сервисов пароль пользователя генерирует платформа и кладёт его в
секрет Vault РОДИТЕЛЬСКОГО инстанса. vault_secrets родителя — Computed и обновляется
только при его Read, поэтому внутри одного apply после create_user пароль недоступен
(Invalid index). Из-за этого в pg/outputs.tf приходилось читать vault_secrets кластера,
а стенду требовались два apply.
Решение: подресурс-пользователь отдаёт пароль СВОИМ выходом сразу после create_user.
- types.go: GenSubresource.VaultUserPassword (признак из данных спека);
- loader.go: признак = подресурс user + у сервиса есть vault-выходы + create_user
принимает username и НЕ принимает password; имя сервиса нигде не проверяется;
- templates/subresource.go: поле модели + Computed/Sensitive атрибут password,
чтение Vault родителя в Create (GetInstanceStateDetails + GetInstanceVaultSecrets)
и перенос уже полученного пароля в Update (чтобы Computed-атрибут не стал unknown);
- resources_core/subresource_user_password.go: ExtractUserPassword — разбор
{"<username>":{"password":"..."}} с безопасным возвратом пустой строки;
- writers: регрессионный тест «фича включена/выключена».
Проверено генерацией и сборкой test-стенда: выход получили 4 подресурса
(postgres_user, kafka_user, clickhouse_user, mongodb_user); mariadb_user НЕ затронут
(там пароль входной); k8s_*_user и vc_org_user не затронуты (пользователь
адресуется не через username). go test ./... — ok, go build — чисто.
Записал в ОБЩИЙ файл архитектуры (TOOLS/ARCHITECTURE.md, PRIMARY SOURCE OF TRUTH):
- раздел «Subresource-born secrets» в Subresource Resources — проблема, принцип,
правило «service-specific DATA, never logic», факт postgres vs mariadb;
- пункт 3 в Exception Registry — как объявлять признак в YAML-спеке и прокидывать
через types.go + loader.go, без svc.Name == "..." в шаблоне.
В provider_philosophy.md оставлена короткая ссылка на ARCHITECTURE.md (источник один).
В раздел 6 (Подресурсы) добавлен подраздел про секреты, рождаемые операцией
подресурса:
- проблема: vault_secrets родителя — Computed, обновляется только в Read, поэтому
после create_user пароль недоступен в том же apply (Invalid index);
- принцип: пароль должен быть выходом самого подресурса, не читаться из родителя;
- как привязано к данным, а не хардкодом: признак в YAML-спеке (по аналогии с
suspend_on_destroy_default), условный блок в общем шаблоне;
- факт из спеков: postgres = пароль генерит платформа (нужен выход), mariadb =
пароль задаёт пользователь на входе (выход не нужен).
README читает человек впервые — ему нужны структура, шаги запуска и операции,
а не разбор прошлых костылей. Удалено:
- раздел «Почему нельзя создать всё одним apply» с историей про try() и PGPASSWORD;
- упоминания try() в apps/lucee.tf, apps/flask.tf, apps/nodejs.tf;
- «data-source/backend» из apps/locals.tf и путь к удалённому разделу из pg/outputs.tf.
Заодно удалён старый TEST_STAND/CRUD/terraform.tfvars (не читается, значения
перенесены в pg/terraform.tfvars и apps/terraform.tfvars).
Проверено: terraform validate — Success в pg/ и apps/ (apps — с временным creds.json).
Было: одна папка, один state — destroy убивал и БД, и приложения; пароль БД
приходилось вытаскивать костылём try() в одном apply, приложения поднимались
с пустым PGPASSWORD.
Стало:
- pg/ — кластер PostgreSQL + пользователь + база + outputs (хост/порт/юзер/база/пароль);
destroy здесь переводит кластер в Suspend, а пользователь и база не удаляются
(keep_on_destroy = true + adopt_existing_on_create = true);
- apps/ — три приложения-потребителя; креды БД читаются из creds.json (выгрузка
outputs папки pg/, т.к. state раздельные, а data-source у провайдера нет);
try() убран полностью — пароль к моменту этого apply уже существует;
- apps/.gitignore — creds.json, terraform.tfvars, state/lock;
- README.md переписан: структура, «зачем разделено», пошаговые 3 шага запуска,
повседневные операции (destroy приложений не трогает БД), про destroy базы.
Проверено: terraform init+validate в обеих папках — Success;
plan в pg/ — 3 to add (кластер, пользователь, база) + 6 outputs.
- VERSIONS.md: три строки обновлены, добавлены первые 16 символов sha256 каждой сборки;
- HISTORY: что заливалось, как проверялось (схема 60/62 ресурсов, исключения —
action-шаблон mongodb_rollback и рукописный service_operation), грабли
checksum mismatch при той же версии + лечение, и найденный факт: state
TEST_STAND/CRUD пуст (serial 38), инстансы в облаке помечены deleted.
Инстанс PG при destroy уходит в Suspend (suspend_on_destroy_default: true в
90_postgres.yaml), а не удаляется. Без keep_on_destroy подресурсы (create_user/
create_database) удалялись бы из живого кластера — после resume приложения
работали бы с пустой БД, данные базы были бы потеряны.
keep_on_destroy=true → режим state_only: при destroy подресурс остаётся в облаке
и только убирается из state. В паре с adopt_existing_on_create=true следующий
apply усыновляет существующий объект, а не падает на 'уже существует'.
Проверено: terraform validate — Success (провайдером 3.0.0, где атрибут есть).
Проверяет три части фичи в сгенерированном коде:
1) поле модели KeepOnDestroy с тэгом tfsdk:keep_on_destroy;
2) атрибут схемы Optional + Default=false (поведение по умолчанию не меняется);
3) в Delete проверка флага идёт РАНЬШЕ вызова операции удаления — иначе destroy
всё равно удалял бы объект в облаке.
Вывод генератора перед сравнением нормализуется по пробелам: gofmt выравнивает
поля структур и ключи map, из-за чего поиск подстроки «как в шаблоне» не работает.
Запуск: cd TOOLS/resource-generator && go test ./internal/writers/... — ok.
- у подресурсов появился раздел «Поведение при destroy» с таблицей флагов
(keep_on_destroy / skip_missing_on_delete / adopt_existing_on_create) и предупреждением
про расхождение state и облака;
- в блоке destroy у инстансовых ресурсов добавлен keep_on_destroy (раньше не документировался
вообще ни на одной странице);
- в types добавлено поле Lifecycle.KeepOnDestroyDefault.
Проверено генерацией: keep_on_destroy упоминается на 49 страницах test-стенда,
включая postgres_user.md (подресурс) и postgres_params_create.md (инстанс).
Подресурсы (nubes_postgres_user/database и остальные 20) удалялись всегда, даже когда
родительский инстанс при destroy только приостанавливается. Из-за этого пользователь БД
удалялся, а следующий apply создавал его заново с НОВЫМ паролем.
Добавлен атрибут keep_on_destroy (как у инстансовых ресурсов, Default=false):
- поле KeepOnDestroy в модели;
- атрибут схемы (Optional+Computed, Default=false);
- ранний выход в Delete с предупреждением (режим state_only).
Проверено: 22 подресурса получили атрибут; сборка провайдера с перегенерённым кодом — BUILD_OK.
Дефолт false → поведение существующих конфигураций не меняется.
Новая страница docs/curated/crud/three_apps.md (раздел «Проверенные примеры» в mkdocs.yml):
- что создаётся (6 ресурсов: PG + user + db + Lucee + Flask + Node.js);
- ссылки на git: gitea.services.ngcloud.ru/terraform/{tfluceecrud,tfflaskcrud,tfnodejscrud}
(проверено HTTP 200), в манифестах — lucee_git_path/flask_git_path/nodejs_git_path;
- запуск: два apply и почему (пароль появляется только после create_user);
- доступ к БД: vault_secrets["users"] -> { "<username>": { "password" } }, и ловушка
state_out.users (метаданные без пароля);
- особенности: adopt_existing_on_create, уникальные домены, camelCase в postgres_conf, realm;
- диагностика: ошибку смотреть в stages операции, а не в errorLog.
Проверено локальной сборкой mkdocs: страница собирается, битых ссылок нет,
все три ссылки на репозитории присутствуют в HTML.
Раньше locals читали пароль напрямую: jsondecode(vault_secrets["users"]).user4crudpg.password.
При первом apply пароля ещё нет (create_user выполняется после создания кластера), поэтому
Terraform падал с «Invalid index ... does not identify an element in this collection value».
Теперь через try(... = ""): на первом apply в env идёт пустая строка и прогон не роняет;
на втором apply пароль уже в Vault, try возвращает настоящее значение, приложения получают верный env.
Комментарии в lucee.tf/flask.tf/nodejs.tf объясняют зачем try и почему два apply.
Проверено: terraform validate — Success; plan — No changes; Exit 0.
Проверено по API 2026-10-01 (pg4crud2, TEST):
GET /instances/<uid>/vault/users -> {"users":{"user4crudpg":{"password":"..."}}}.
Пароль ЕСТЬ; state.out.users — метаданные без пароля (их легко перепутать).
- README.md: строка навигации «Пароль БД / секреты Vault» + раздел «Грабли, на которые уже наступали»
(Invalid index из-за одного apply; errorLog врёт — смотреть stages; лишний sensitive).
- docs/curated/postgres/pg_user_db.md: раздел «Пароль пользователя БД и секреты Vault» (ловушки,
два apply, диагностика через /instanceOperations?fields=stages); исправлено утверждение «все 4 ресурса
за один apply» — для приложений, читающих пароль, нужен второй apply.
- docs/30_registry/guides/getting-started.md: помечены устаревшие ключи adminUser/adminPass (сейчас 404).
- HISTORY/2026-10-01_...: дополнение с фактами и указанием, что первый разбор ошибся.
Зафиксировано по журналу операции 181D3B1D (GET /instanceOperations/<uid>?fields=stages):
падение на шаге «1. Валидация» → «Проверка ёмкости рес платформы»:
«Невозможно развернуть приложение в данной ресурсной платформе».
errorLog «Invalid JSON String» сути не отражает.
Отдельно отмечено, что не доказано (snake_case в postgres_conf, причины операций
4D60A0B6 и 5AAF1E39 — их stages недоступны, API отдаёт 404) и что моё утверждение
в коммите e3182c3 было предположением, выданным за факт.
Провайдер отправляет postgres_conf на платформу как есть (resources_core.FormatString
возвращает строку без перевода имён), поэтому ключи обязаны совпадать со спекой:
postgresConf.paramName / postgresConf.paramValue. С snake_case (param_name/param_value)
платформа падала с "Invalid JSON String" (операция 5AAF1E39-8812-4994-AD14-78D51ED2077D).
Значение paramValue взято '' — как в HAR/pgmodify.har и в TEST_STAND/PG/resources.tf.
План проходит: 6 to add, exit 0.
Из-за sensitive = true в plan вместо значений печаталось "(sensitive value)".
Убрано в: DEV_STAND/CRUD, DEV_STAND/POSTGRES, TEST_STAND/POSTGRES, TEST_STAND/PGwNewRegistry.
api_token остаётся sensitive везде — он действительно секрет.
realm — не секрет, но из-за sensitive = true в plan вместо имени печаталось
"(sensitive value)". Теперь видно resource_realm = "k8s-3-sandbox-nubes-ru".
Плана это не меняло: plan по-прежнему 6 to add, exit 0.
Прочие sensitive оставлены как есть: api_token (секрет), vault_secrets (платформа).
- lucee/flask/nodejs: добавлен adopt_existing_on_create = true (усыновлять существующий
инстанс вместо падения с «ресурс с таким именем уже существует»)
- удалены git_revision и одноимённые locals (в TEST их нет)
- git_path: Nail -> terraform (проверено по HTTP: /Nail/<repo> отдаёт 301 на /terraform/<repo>)
- terraform.tfvars.example: комментарий s3_user_uid = UUID S3-пользователя
Имена ресурсов и домены оставлены dev-своими (уникальными). realm dev = k8s-3-sandbox-nubes-ru.
Проверка API dev-стенда (/instances?isDeleted=false): 9 инстансов, ни одного под сервисы
89 flask / 94 lucee / 95 nodejs и PostgreSQL; поиск crud|pg4|lucee|flask|nodejs -> 0. Коллизий нет.
НЕ исправлено (не моя правка, есть и в HEAD): terraform validate падает на nubes_nodejs.json_env —
в спеке dev-стенда у сервиса 95 объявлен обязательный sub_param DB_PASS, поэтому схема требует
объект { db_pass }, а конфигурация передаёт строку jsonencode().
vm.tf целиком обёрнут в блочный комментарий /* … */ со пояснением причины:
в test инстанс vApp не прошёл валидацию схемы (нужен reconcile). Вернуть —
удалить обрамляющие строки.
Проверено: terraform fmt -check OK, validate Success,
plan = 1 to add (только Штурвал); инстансов vApp/ВМ стенда в тенанте нет (все deleted).
Первый apply в test: vdc/edge/org_ip/snat создались; упали:
- Штурвал: 'свободных Ip в тенанте WZ03709-iaas: 1, необходимо 2' — на NaeelOrg
было count=10, часть адресов держит кластер iot-naeel. Поднято до 12.
- vApp: 'не удалось валидировать схему инстанса' -> not created (вероятно плавающая,
при повторе — reconcile).
После destroy (владелец): fullpipe-vdc = suspended (suspend_on_destroy),
fullpipe-edge = running (keep_on_destroy), локальный state пуст.
Порядок: apply -target=nubes_vc_org_ip_allocation.org_ip -> полный apply.
HISTORY/2026-10-01_test_stand_fpipegmail.md дополнен разделом с ошибками и решением.
Создана папка (без .terraform/state/lock — это состояние dev). Изменены параметры:
- versions.tf: nubes-dev/nubes 2.0.1 -> nubes-test/nubes 3.0.0;
- variables.tf: api_endpoint -> lk-api-gateway-test.ngcloud.ru;
- terraform.tfvars: organization=NaeelOrg (найдена через API, svc 19), ip_count=10
(в test на орге уже выделено 10 IP), storage SSD (в test vDC строят на SSD);
- shturval.tf: shturval-test1 / shturval-test-01 / workers-shturval-test.
Коллизии проверены: в test заняты naeel-vdc, 'VDC для кластера iot-naeel',
naeel_vc_nsxt, 'Edge для кластера IOT naeel', 'Кластер Kubernetes [iot-naeel]' —
наши имена (fullpipe-vdc/-edge/-vapp-02, web02, shturval-test1) свободны.
Проверено: terraform init (3.0.0), fmt -check OK, validate Success,
plan = 7 to add / 0 change / 0 destroy. apply НЕ запускался.
Документация: HISTORY/2026-10-01_test_stand_fpipegmail.md
Полный цикл 03 (01 YAML -> 02 Go/доки -> сборка 3 платформ -> GPG -> S3) по каждому стенду
начиная с YAML. Профиль dev: VERSION 2.0.1 -> 2.0.0 (db9d93e).
Проверено: sha256 залитого linux-бинарника == локальной сборке на всех трёх
(prod 9c20e0a7, test 9cdfa8b8, dev 86c667f7); по 5 объектов на версию; YAML 36/36/40.
Отличие от заливки 30.09: теперь в сборки вошли 8 коммитов правок ядра/генераторов
(core, resources_core, resource-generator, check_schema_names + вызов в 03).
Документация: HISTORY/2026-10-01_release_x_0_0_all_stands.md, VERSIONS.md.
jlib.tofu не смог зарезолвить provider vmware/vcd через terraform-mirror.yandexcloud.net:
'internal DNS 169.254.25.10:53: server misbehaving' -> 'Edge не удалось найти в Cloud Director'
(операция не выполнилась). Проверено извне: зеркало доступно (DNS резолвится, index.json HTTP 200,
0.88s) => проблема во внутреннем DNS/сети платформы, не в зеркале.
Ошибка модификации Edge nsx_WZ03709-saas-tbxiw8kt: FORBIDDEN 'Cannot disable load
balancer ... since there are Pools'. Пулы остались от неудалённых CAPvcd/Штурвала;
пока они есть — ALB не отключить и Edge не удалить. Клиентских путей нет,
нужна платформа (заявка расширена: CAPvcd + LB Pools + затем Edge).
Владельцу не удаётся удалить Edge: платформа блокирует из-за инстансов CAPvcd
(shturval-dev-01), хотя кластер удалён из ЛК 25.09.
Установлено (API dev): shturval-dev1 (svc 150, uid 05ae1dbc-…) — deleted, операций нет;
тенанта WZ03709-saas в dev нет (единственная организация — kontra).
Попытка доудаления (по указанию владельца):
POST /instanceOperations (svcOperationId=109, delete) -> 201, run -> 201,
результат: isSuccessful=false, errorLog="Cannot invoke \"String.length()\" because
\"text\" is null" — NPE бэкенда. Остатки CAPvcd не вычищены.
Вывод: только техподдержка (MAN vc_org прямо это предписывает).
Инцидент 2026-09-30 показал: невалидное имя атрибута (s3-inst) проходило генерацию,
сборку и заливку, а ломалось только у пользователя (Terraform отвергает схему целиком).
- TOOLS/scripts/check_schema_names.sh: проверяет все tfsdk:"..." в сгенерированном Go
на [a-z0-9_]; exit 1 при нарушении, с подсказкой про helpers.ToSnake.
- 03_build_and_upload_provider.sh: вызов стража после 02 (до сборки и заливки).
- ARCHITECTURE.md: страж добавлен в список enforced-скриптов.
- HISTORY: пункт 'не закрыто' заменён на 'закрыто' с проверками.
Проверено: dev/test/prod -> OK; искусственный пример (tfsdk:"s3-inst") -> exit 1.
Инцидент: в 1_dummy (API dev) появились коды s3-inst / s3-ref-root. ToSnake не убирал
дефисы -> в схему уходило tfsdk:"s3-inst" -> Terraform отвергает такие имена и НЕ
загружает схему провайдера целиком (plan/apply падали).
- helpers.go: ToSnake завершается sanitizeAttrName ([a-z0-9_] допустимы, остальное -> _).
Код для API не меняется: json:"s3-inst" в генерате сохранён.
- Проверено: в generated/dev/go нет tfsdk-имён с недопустимыми символами;
go build OK; go test ./internal/... -short PASS.
- DEV_STAND/FPipeGmail: провайдер 2.0.23 -> 2.0.1; после сброса lock/кэша
terraform validate -> Success.
- HISTORY: описан инцидент, причина (данные API изменились после утра), фикс и
особенность: перезапись артефакта под тем же номером требует сброса lock
(init -upgrade хеш не пересчитывает).
dev 2.0.1 перезалит (sha256 linux d25a71a31dbc9ab16e494b3d1f68b38b2214bd530045c5a3003f515bc725e407).
Файл ВМ включён в конфигурацию (был .tf1 — Terraform его не читал).
Дефолты переименованы, т.к. инстансы со старыми именами есть в облаке,
сломаны и не удаляются:
- vapp_resource_name: fullpipe-vapp -> fullpipe-vapp-02
- vapp_name: fullpipe-vapp-01 -> fullpipe-vapp-02
- vm_resource_name: fullpipe-vm-01 -> fullpipe-vm-02
- vm_name: web01 -> web02
Проверено: terraform validate -> Success (в DEV_STAND/FPipeGmail).
Цикл 03 (01+02 -> сборка linux/windows/darwin -> SHA256SUMS -> GPG -> S3) по dev.
Версия 2.0.1 (ранее удалена при чистке, создана заново).
Проверено:
- sha256 локальной сборки == SHA256SUMS (linux/amd64, 13 172 824 B);
- GET /v1/providers/nubes-dev/nubes/versions -> содержит 2.0.1;
- download linux/amd64 2.0.1 -> HTTP 200;
- в S3 5 объектов (3 zip + SHA256SUMS + .sig), 37.92 MiB.
test и prod не перезаливались (правки ядра туда не включены).
Документация: VERSIONS.md, HISTORY/2026-09-30_dev_release_2_0_1.md.
Код-ревью (раунд 5), п.1/6: pre-check брал схему из GET /instanceOperations/default/{opId},
а payload строился по живой схеме ?fields=cfsParams — два источника. default может
расходиться с живой => риск ложного пропуска modify.
Решение: pre-check вообще не запрашивает схему.
- modifierDesiredEqualsLive(ctx, uid, desired): сравнение по live-кодам
(live[lower(code)]), единственный источник — state.params.
- Значения: похожи на JSON ({/[) — смысловое сравнение; иначе скалярное с
нормализацией (null/"" -> ""; true/false без учёта регистра) — закрывает и
регистр bool.
- Fail-safe сохранён: пусто/нет кода/ошибка live => modify выполняется.
- Удалены: fetchOperationSchemaByID, modifierValuesEqual, lookupLiveParam больше
не участвует в pre-check (остаётся для досылки).
- Тесты переписаны (RawValuesEqual_Scalars/JSON, DesiredEqualsLive: 4 кейса).
Документация: TOOLS/ARCHITECTURE.md -> новый раздел «Modifier Idempotency»
(5 правил контракта); HISTORY — журнал раунда 5.
Проверено: go build ./... OK; go test ./internal/... -short PASS.
- Q1: POST не ретраится (не идемпотентен; Idempotency-Key у API нет) — решение.
- Q2: при ошибке после POST /instanceOperations и до run операция остаётся черновиком;
отмены нет (ни в коде, ни в HAR — DELETE /instanceOperations/{uid} отсутствует).
- Q4: единый контракт жизненного цикла — keep_on_destroy + suspend_on_destroy;
delete_strategy (YAML) = маппинг на них (noop_warn/inverse/error).
Проблема: CreateGenericInstanceUniversalV6 при ЛЮБОЙ ошибке после создания инстанса
возвращал "", а шаблон Create при ошибке не писал ID в state => облачный инстанс
осиротевал (Terraform о нём не знает, повторный apply упирается в страж дубликатов).
- core/instance_create.go: ошибки после получения instanceUid возвращают uid вместе
с ошибкой (POST /instanceOperations, пустой opUid, разбор cfsParams, resolve,
отправка параметров, validate, run, waitForOperationFinish, ensureInstanceCreated).
До создания uid — по-прежнему "".
- templates/instance.go: при err != nil и id != "" -> data.ID + resp.State.Set (partial
state), затем AddError.
- client_test.go: TestCreateGenericInstance_KeepsUIDWhenOperationCreateFails,
TestCreateGenericInstance_EmptyUIDWhenInstanceCreateFails.
- ARCHITECTURE.md: пункт про partial state.
Проверено: 02 (dev) + dev-materialize -> 40 файлов resources_gen содержат фикс;
go build ./... OK; go test ./internal/... -short PASS.
Замер по generated/dev/resources_yaml (40 файлов, только чтение):
- required-параметров: 852; с пустым data_type — 5;
- всего с пустым data_type: 12 (~1.2%); угадывание по имени даёт != '' только
для 1 тестового (1_dummy.jsonExample) => гипотеза A4 не подтверждается,
правка косметическая, не исправление дефекта.
- NOTES/20_prompts/prompt_for_opus_remediation_round4.md — 5 коротких вопросов
(retry POST, осиротевшая операция, zero-value по подстроке, единый словарь
жизненного цикла, что упущено в ядре); ответ ≤ 25 строк.
- HISTORY/2026-09-30_core_and_modifiers_remediation.md — журнал: 6 коммитов,
что отклонено (A3/A4/A5) и почему, что отложено (A2/B8/B9).
- core/refsvc.go: комментарий ссылался на несуществующий блок 'Restore user-provided
casing' в instance.go. Факт: ref_svc исключены из read-back (InputField только при
RefSvcId==0), UUID внутри JSON нормализуются при отправке (BuildJSON ->
LowercaseUUIDsInText).
- docs/60_strategy/terraform_case_sensitivity_fix.md: §4 помечен как историческая
справка (подхода originalVappUid в коде нет); актуальные §10-§11.
Проверено: go build ./... OK; go test ./internal/... -short -> PASS.
Проблема: modifierDesiredEqualsCurrent сравнивает desired с paramValue из cfsParams
(дефолт ФОРМЫ операции), а не с состоянием инстанса. Пропуск modify на такой основе
может быть ложным (HAR/edge_.har: needEnableAVI paramValue=false при live=true).
- core/modifier_compare.go: добавлен modifierDesiredEqualsLive (источник —
instanceLiveParams/state.params; неопределённость => не пропускаем) и хелперы
modifierValuesEqual / modifierCodeMap; modifierDesiredEqualsCurrent переведён на них.
- core/operation_run_bycode.go: idempotent-путь использует live-pre-check; при ошибке
чтения live modify НЕ пропускается.
- resources_core/nsxt_snat_resource.go: setSnat -> RunInstanceOperationUniversalByIdempotent
(лишний modify на повторном apply больше не отправляется).
- modifier_compare_test.go: TestModifierDesiredEqualsLive (совпало/отличается/live недоступен).
Проверено: go build ./... OK; go test ./internal/core/... -short -> PASS.
isRetryable (core/http.go): добавлен StatusUnauthorized (401) к {429,502,503,504}.
Gateway может временно отклонять валидный JWT — без этого одиночный 401 ронял
read/plan/поллинг.
- client_test.go: юнит-тест TestIsRetryable (401/429/502/503/504 = true; 400/403/404/500 = false).
- ARCHITECTURE.md: раздел API Resilience приведён к фактическому поведению
(401 реализован; POST не ретраится намеренно).
Проверено: go build ./... OK; go test ./internal/core/... -short OK.
- Core Principles 2-3: 'универсально/генерируется' отнесено к core/ и resources_gen/,
а не ко всему сервис-коду.
- API Resilience: 401 НЕ ретраится (isRetryable = 429/502/503/504, только GET) —
помечено как незакрытый разрыв со спекой.
- Exception Registry: убран удалённый реестр serviceSpecificModifiers
(yaml-generator/main.go), описаны ручные модификаторы + несуществующий modifiers.yaml.
- Новый раздел 'Lifecycle Vocabulary': три несогласованных словаря destroy.
- Rules: 'two registries' -> один реестр + ручные ресурсы.
DeepSeek верифицирует гипотезы групп A (ядро: 401/POST-ретраи, обрыв modify, zero-value
fallback, нормализация Read) и B (модификаторы/спека), затем даёт план правок кода, правок
документации и архитектурных решений, трёхуровневый план проверки (юнит / plan-apply на
DEV_STAND/FullPipe / регрессия + стражи) и порядок работ по коммитам. Код не пишет — исполнять
будет Copilot. Журнал Opus-диалога дополнен ссылкой на этот шаг.
Записаны: запрос «твоё мнение?» по раунду 2; сообщение с путём к файлу раунда 3 и
отменённый уточняющий вопрос агента; запрос «мнение?» по раунду 3 и полное мнение агента
(в т.ч. сомнение в абсолютном выводе «401 не ретраится нигде» и в трактовке отсутствия
ретрая POST как дефекта). Статус обновлён: чат с Opus исчерпан по токенам.
Дословно сырой лог и отчёт: 5 находок по ядру — 401 не ретраится (расхождение с
ARCHITECTURE.md:105-108), ретрай только для GET, обрыв modify после создания операции,
zero-value fallback по подстроке имени, нормализация Read только для jsonEnv/ref_svc.
Находки 1-3,5 не подтверждены замером.
Жёсткий бюджет ради токенов: ≤10 файлов, ≤5 находок по ≤3 строки, плюс одна строка
«что проверяемо только замером». M6 снят, модификаторы — фон. Границы: ядро, resources_core,
шаблоны/хелперы генератора. В журнал добавлены крит-мнение по раунду 2 и текст раунда 3.
Замечания M1–M5 (сверка номеров строк, нарушение «без догадок» в R2, натянутые S2/S4,
приоритет R5, пробел по устойчивости Read/вечный diff) и U1–U3 (modifiers.yaml не существует,
рассинхрон suspend_on_destroy/keep_on_destroy, корневая причина ручных модификаторов).
Разрешён дополнительный список файлов; право копать глубже передано Opus.
Дословно, без сокращений: задание пользователя, разведка агента, содержимое промпта,
сырой лог сессии Opus и его отчёт (расхождения спека↔код S1–S5, риски R1–R6),
открытый вопрос Opus. Статус: диалог не завершён.
Задача: разбор универсальной архитектуры и слоя модификаторов (nubes_vc_org_ip_allocation,
nubes_vc_nsxt_snat). Жёсткие границы доступа (запрет на HISTORY/NOTES/TMP/HAR/docs и git-историю),
исчерпывающий список из 22 файлов (1 спека + код + YAML-спеки + пример применения),
сжатый формат ответа, режим диалога с правом задать уточняющий вопрос.
Полный цикл 03 (01+02 → сборка 3 платформ → GPG → заливка S3) по каждому стенду:
- prod nubes/nubes 1.0.0;
- dev nubes-dev/nubes 2.0.0 (VERSION в profile.env: 2.0.24 → 2.0.0);
- test nubes-test/nubes 3.0.0.
Проверено: sha256 залитого linux-бинарника == локальной сборке на всех трёх;
API /versions отдаёт 1.0.0 / 2.0.0 / 3.0.0; в S3 по 5 объектов на версию.
Последствия (приняты владельцем): версии X.0.0 перезаписаны → у пользователей
с .terraform.lock.hcl будет checksum mismatch (лечится terraform init -upgrade).
Подробности: HISTORY/2026-09-30_release_1_0_0_2_0_0_3_0_0_all_stands.md
В dev-реестре (s3://nubes-terraform-registry/.../nubes-dev/nubes/) удалены
версии 2.0.0–2.0.20 — 21 версия, 105 объектов (~800 MiB). Бакет un-versioned.
Осталось: 2.0.21, 2.0.22, 2.0.23, 2.0.24 (20 объектов).
Проверено: mc ls (20 объектов), API /versions (4), download 2.0.23/2.0.24 → HTTP 206
(ZIP), 2.0.0/2.0.20 → HTTP 404; nubes-test (3.0.0) и nubes (1.0.0) не тронуты.
Резервные копии zip не делались (прямое указание «стереть физически»);
восстановление — только пересборкой из git-истории.
Документация: HISTORY/2026-09-30_dev_registry_prune_versions.md, VERSIONS.md.
Перенесено из служебной памяти VS Code в файл репозитория:
- пошаговая процедура релиза dev (VERSION → 03 → curl-проверка → VERSIONS.md →
dev-materialize), включая, что доки в реестр не публиковались;
- карта: нормализация нужна в двух местах (сравнение и отправка BuildJSON),
перечень функций и правила (lower() — костыль; план целиком не нормализуем).
Перенесено в файл репозитория (а не только в служебную память VS Code):
- результаты полной перегенерации и перепроверки всех трёх стендов;
- подводные камни: случайные default от API (детектор дрейфа по побайтовому
сравнению не работает); случайный default вшивается в Go-код → drift 15 файлов
сразу после перегенерации; generated/<стенд>/go|docs стареют после шага 01;
403 без браузерного User-Agent (DDoS-Guard);
- актуальная карта пайплайна, токены, что удалено и что оставлено осознанно.
Зафиксирована методика: истина = GET /services?isProductionReady=true
(без фильтра API отдаёт все сервисы платформы, включая DEPRECATED).
Результаты по dev/test/prod и исправление prod (Vault).
Сверка TOOLS/config/prod/services_list.txt с облачным каталогом
(GET /api/v1/svc/services?isProductionReady=true → 36 сервисов):
- активных в файле было 35, лишних нет, но не хватало 151 k8sOpenbao (Vault);
- комментарий «нет в PROD UI» устарел: сервис отдаётся каталогом prod
(isProductionReady=true, resourceRealmTypeId=3).
После правки: 36 активных = 36 в облаке, перегенерация prod дала 36 YAML,
включая 151_k8s_openbao.yaml. dev (40/40) и test (36/36) расхождений не имели.
- раздел «Этап 2» с таблицей удалённых файлов и обоснованием;
- зафиксировано, что НЕ удалено и почему (index.cfm-совместимость,
справочная копия DOCS_PIPELINE/publish-docs.sh, исторические документы);
- результаты проверок после удаления (bash -n, smoke-прогон 01 dev).
Удалено (100% мёртвое, ничего не вызывает):
- TOOLS/scripts/10_yaml_stability_run.sh
- TOOLS/scripts/11_yaml_stability_run_latest.sh
- TOOLS/scripts/12_generate_yamls_latest.sh
- TOOLS/scripts/13_generate_yamls_clean.sh
- TOOLS/scripts/02_generate_resources_and_docs_template_v2.sh
- TOOLS/config/services_list.txt (общий список: код его не читает, а как
«объединение» он устарел — в нём активен id 27, который в test/prod
закомментирован как «нет в UI», и отсутствуют 87/88/97/153 из dev)
Все ссылки в документации указывали на профильные списки либо будут
исправлены отдельным коммитом.
- TOOLS/README.md: раздел «Канонический пайплайн (порядок шагов)» и описание
безопасной генерации (staging → атомарная замена, бэкапы, маркер .stand);
- TOOLS/ARCHITECTURE.md: ссылки devops/… → TOOLS/config/<stand>/…;
- HISTORY/2026-09-30_yaml_pipeline_hardening.md: полная история изменений
(что было не так, что сделано, прогон по стендам, коммиты, проверки).
10/11/12/13 + 02_..._template_v2 нерабочие (зовут 01 без --profile, ищут
*.token в корне репо) и не вызываются никаким рабочим скриптом (ссылки —
только в исторических HISTORY/NOTES). Теперь падают сразу с подсказкой
канонического пути вместо мнимой работы; 13 вдобавок больше не может
сделать rm -f provider/resources_yaml/*.yaml.
Проверено: bash -n OK, guard отдаёт exit 2.
- resources_core.BuildJSON оборачивает результат в jsonutil.LowercaseUUIDsInText:
платформа сравнивает регистр UUID при create, а ресурсы отдают id в UPPERCASE
(nsxtUid/vdcUid) -> без нормализации create Штурвала падал 'Edge не развёрнут
в указанном vDC' (обнаружено на провайдере 2.0.23 из-под Windows).
- Одна точка покрывает все map-fixed-параметры (create/modify/redeploy),
регенерация не требуется.
- Документация: HISTORY/2026-09-30, docs/60_strategy/terraform_case_sensitivity_fix.md §11,
NOTES/30_analysis/ARCHITECTURE_NEW.md §6.5, docs/help/architecture-and-methods.md §7.
Не выпущено: версия не поднималась, релиз/регенерация не выполнялись.
Repinoid