- в таблицу правок добавлен коммит 272d405 (клонирование, шаг 4 с адресами,
диагностика, суффикс nodejsk8s);
- в раздел про ручную публикацию: страница перезаливалась дважды, после правок
на живой странице 167269 байт, cmp с локальной сборкой совпал;
- в «Мои ошибки»: склейка двух строк таблицы «Файлы» из-за замены строки вместе
с переводом строки (обнаружено и исправлено); отсутствие в README входа
(клонирование) и выхода (адреса приложений).
Проверено: все четыре вставки на месте, структура файла цела.
Владелец: «где про клонирование?? глазами юзера просмотри весь текст». Пройдено
по тексту целиком, добавлено то, без чего пользователь не начнёт и не проверит:
- раздел «Где взять манифесты»: git clone terraform/tf_provider, cd
TEST_STAND/CRUD, проверка terraform version, откуда берётся провайдер и какой
версии (обе папки: nubes-test/nubes 3.0.0);
- раздел «Запуск» стал «четыре шага»: шаг 4 «Проверить» с реальными адресами
(lucee-crud.luceek8s.dev.nubes.ru, flask-crud.pythonk8s.dev.nubes.ru,
nodejs-crud.nodejsk8s.dev.nubes.ru) и командой, как посмотреть свои адреса в
state; проверено грепом по apps/terraform.tfstate;
- заменена заглушка <суффикс> на фактический суффикс nodejsk8s;
- добавлен раздел «Если apply упал» (журнал операции вместо errorLog);
- в «Файлы» добавлены terraform.tfvars.example;
- шаг 3: формулировка про имена приведена к исправленной (задаются в locals.tf).
Одновременно исправлена моя ошибка: предыдущая правка склеила две строки
таблицы «Файлы» (pg/main.tf и pg/postgres.tf) — восстановлено.
То же продублировано в docs/curated/crud/three_apps.md (файлы обязаны совпадать).
Проверено: 260 и 265 строк, блоки кода парные (22 и 24), заголовки на месте.
HISTORY (раздел 5, раздел с ошибками стал 6):
- сборка test-стенда без публикации (S3CFG_REGISTRY в несуществующий путь —
штатного флага «build-only» у 04 нет);
- заливка в S3 (алиас regdocs из secrets/.s3cfg_registry) и копирование на ВМ
в /var/www/tf-docs/nubes-test/curated/crud/three_apps/ — сайт отдаёт nginx с ВМ,
а не из S3;
- проверка: живой URL 200, 163789 байт, cmp с локальной сборкой совпадает,
version 3.0.0, 5.0.5 нет;
- ограничение: в меню других страниц ссылки нет (их навигация старая);
- заметка: ssh naeel@5.172.178.213 без алиаса не пускает, нужен алиас vps;
- в «Мои ошибки» добавлена неверная формулировка про домены.
TODO: добавлен раздел «Что уже сделано вручную (временно)» и следствие — полная
пересборка нужна, чтобы пример появился в меню, а версии совпали с profile.env.
Проверено: разделы 1-6 в HISTORY, структура TODO на месте, блоки кода парные.
Правка владельца: в *_domain лежит не домен, а имя, из которого платформа сама
строит полный домен (lucee-crud -> lucee-crud.luceek8s.dev.nubes.ru,
flask-crud -> flask-crud.pythonk8s.dev.nubes.ru), а уникальны именно полные имена.
Было: «уникальны в облаке — один домен нельзя повесить на два инстанса».
Исправлено в TEST_STAND/CRUD/README.md и в docs/curated/crud/three_apps.md (они
обязаны совпадать).
Проверено: формулировка одинаковая в обоих файлах, собрана и опубликована страница.
В docs/TODO/docs_publish_stale_versions.md зафиксировано:
- проблема: на nubes-test в примерах версия 5.0.5 (в profile.env 3.0.0), на
nubes-dev 2.0.23 (2.0.0), prod 1.0.0 совпадает;
- причина: {{VERSION}} подставляется при сборке из profile.env (04:185-198),
сайты не пересобирались после смены нумерации 2026-09-03;
- что сделать: 04 --profile dev/test + заливка mc mirror с ВМ 5.172.178.213
(команды из DOCS_PIPELINE/README.md), затем проверка версий на живых страницах;
- что уедет заодно: правки curated/crud/three_apps.md (ab9f7d2, 39849bf),
страницы k8svalkey/k8s_ziti_controller/nodered/nifi;
- предупреждения: публикация = деплой (только по команде), публикация без версии
в URL со стиранием старых файлов, риск root-овой сборки site/.
В HISTORY-записи раздела 4 добавлена ссылка на этот TODO.
Проверено: 2 блока кода (чётно), раздел «Связанные документы» на месте.
Проверено по запросу владельца (страница nubes-test/curated/postgres/pg_user_db):
- nubes-test: на сайте 5.0.5, в profile.env 3.0.0 — устарел;
- nubes-dev: на сайте 2.0.23, в profile.env 2.0.0 — устарел;
- nubes (prod): 1.0.0 = 1.0.0 — совпадает.
Причина: в исходнике плейсхолдер {{VERSION}} подставляется при сборке из profile.env
(04:185-198), значит сайты собраны до смены нумерации 2026-09-03 и с тех пор не
пересобирались. Подтверждение: на nubes-test нет страниц, которые есть на nubes-dev
(k8svalkey, k8s_ziti_controller, nodered, nifi), и нет сегодняшних правок
curated/crud/three_apps.md. Локальный site/ (28.09 09:40) — сборка dev, 5.0.5 в нём нет.
Публикацию не запускал: это деплой, ждёт команды.
Проверено: раздел на месте, нумерация разделов файла 1-5.
Вместо раздела «Открытый вопрос» — таблица «Пуш»: tf_provider 4197a76..17ba645
(58 коммитов), tf_examples df44774..d9bc08f, tfnodejscrud 23338cb..3fdda9e;
остальные пять уже были синхронны. Там же зафиксировано, что переформатирование
views/index.ejs (3fdda9e) не меняло разметку и EJS-выражения.
Проверено: HEAD = origin/master по всем восьми репозиториям, незакоммиченного нет.
HISTORY/60_stands/2026-10-02_crud_repo_paths_terraform_org.md:
- что было неверно: Nail/tfluceecrud|tfflaskcrud|tfnodejscrud в tf_examples/CRUD
(locals.tf и README.md) вместо terraform/*;
- таблица перепроверки всех путей анонимным git ls-remote: приложения CRUD — в
terraform/*, IOT (tf-iot-*) и сам tf_examples — в Nail/*; старые адреса отдают 301;
- что проверено и оказалось верным: TEST_STAND/CRUD/apps/locals.tf,
DEV_STAND/CRUD/locals.tf, docs/curated/crud/three_apps.md, локальные клоны;
- что добавлено в TEST_STAND/CRUD/README.md (раздел «Код приложений (git)», 3f05d79)
и почему там нет git_revision (в стенде такого поля нет);
- открытый вопрос: коммит d9bc08f в tf_examples не запушен в gitea.
HISTORY/README.md: строка записи + счётчики 7->8 и 76->77.
Проверено: на диске 8 файлов в 60_stands и 77 всего — совпало со счётчиками.
В README стенда не было путей к репозиториям приложений. Добавлен раздел перед
«Запуск — три шага»: таблица со ссылками на terraform/tfluceecrud, terraform/
tfflaskcrud, terraform/tfnodejscrud и указание, что пути задаются в apps/locals.tf.
Про git_revision не написано — в этом стенде такого поля нет (проверено grep:
в apps/*.tf только version/git_path/health_path).
Проверено: раздел на месте, фаерсы 14 (чётно).
- в таблицу правок README: 7b63f12 (раздел «Что пользователь задаёт сам») и
39849bf (тот же раздел на странице сайта);
- в раздел про страницу сайта: отметка о синхронизации и проверке diff;
- в «Мои ошибки»: дважды пропустил главное для новичка — какие параметры он задаёт
сам и что имена/домены обязаны быть уникальными.
Проверено: файл читается, разделы на месте.
Стендовый README и страница curated/crud/three_apps.md описывают одно и то же,
поэтому раздел перенесён в страницу сайта сразу после «Структура манифестов»:
- обязательные значения (api_token, realm, s3_name) и создание terraform.tfvars;
- имена с правилами уникальности (кластер и приложения — в пределах стенда,
юзер/база — в пределах кластера, домены — в облаке) и объяснение через
adopt_existing_on_create (crud.go:171, refsvc_find.go:47);
- что можно не задавать (дефолты pg/main.tf).
Из шагов 1 и 3 убраны дублирующие таблицы — вместо них ссылка на раздел.
Плюс выровнены отступы в блоке cp terraform.tfvars.example (в двух файлах было
по-разному).
Проверено: diff разделов — совпадает построчно, отличие только в разделителе «---»
(есть в README, не используется на странице); страница 228 строк, 18 строк с
блоками кода (чётно).
Замечание владельца: в README не было видно, какие параметры юзер задаёт СВОИМИ
значениями, и не сказано про уникальность домена и имени инстанса.
Добавлен раздел (сразу после «Как это устроено»):
- обязательные значения: api_token (pg+apps), realm (pg+apps, одно и то же),
s3_name (pg) + команды создания terraform.tfvars в обеих папках;
- имена, которые нужно придумать: pg_resource_name и *_resource_name приложений —
уникальны в пределах стенда; pg_username/pg_db_name — в пределах кластера
(служебные admin/postgres/standby платформа не примет); *_domain — уникальны
в облаке;
- почему: adopt_existing_on_create ищет инстанс по имени внутри сервиса
(provider/internal/resources_core/crud.go:171, provider/internal/core/refsvc_find.go:47),
поэтому при занятом имени провайдер не создаёт новый ресурс, а усыновляет
существующий; без adopt — падает с «уже существует». Пример: tflucee/tfflask/
tfnodejs заняты старыми инстансами (apps/locals.tf:45,57,68);
- что можно не задавать: перечислены дефолты pg/main.tf и размеры в apps/locals.tf.
Из шагов 1 и 3 убраны дублирующие таблицы — теперь ссылка на раздел, комментарии
в командах поправлены («см. таблицу ниже» больше не существует).
Проверено: 190 строк, 14 строк с блоками кода (чётно), заголовки на месте.
HISTORY/50_docs/2026-10-02_crud_docs_page_and_manual_pages_pipeline.md:
- правки README стенда (5fdbc31 раздел «Как это устроено» без натянутых терминов,
6ef003b apply+destroy, 5674b86/b8f5238 справка по выходам pg и перенос в конец);
- переписанная страница сайта curated/crud/three_apps.md (ab9f7d2): таблица «было -> стало»;
- разбор пайплайна: что копируется в docs_dir (04:157-173), запрет использовать docs/
целиком (04:94), docs_dir = generated/<стенд>/docs (04:95-98), nav/exclude_docs
(mkdocs.yml:52 и 4-15), подстановка плейсхолдеров (04:182-198), публикация (04:344);
два способа публиковать ручные страницы: A (в docs/curated + nav — сделано) и
B (добавить копирование в 04 — НЕ сделано, ждёт команды);
- раздел «Мои ошибки»: неверный термин decoupling, однобокая формулировка про destroy,
скрытый факт про ручной creds.json.
HISTORY/README.md: строка новой записи в 50_docs, счётчики 9->10 и 75->76.
Проверено: в 50_docs 10 файлов, всего 76 файлов (кроме README), счётчики совпали.
Страница curated/crud/three_apps.md описывала старую схему: всё в одной папке,
два apply и пароль из vault_secrets кластера через try(). Это уже не так.
Переписана по TEST_STAND/CRUD/README.md:
- два каталога = два state, apply/destroy в каждом меняет только своё;
- три шага: pg/ -> terraform output -json > ../apps/creds.json -> apps/;
- пароль берётся из выхода подресурса nubes_postgres_user (не из vault_secrets);
- раздел «Структура манифестов» и новый раздел «Справка: выходные параметры pg/»
(состав выходов, вид JSON {sensitive,type,value}, соответствие env-переменным
Flask/Node.js/Lucee);
- имена приведены к текущим: lucee-crud / flask-crud / nodejs-crud, пути в
apps/locals.tf, добавлен keep_on_destroy;
- снято непроверенное «состояние на 2026-10-01, все 6 ресурсов running» и строка
про DEV_STAND/CRUD как аналог — там осталась старая плоская схема, сказано прямо.
Проверено: 191 строка, 16 открывающих/закрывающих блоков кода (чётно).
Из шага 2 убран развёрнутый блок (он мешал последовательности трёх шагов),
вместо него одна ссылка. Сам блок стал последним разделом файла
«## Справка: выходные параметры pg/» (уровень заголовка 4 -> 2, т.к. теперь
это самостоятельный раздел, а не подпункт шага 2). Содержимое не менялось.
Проверено: grep заголовков (112: ## Справка), состав файла — 151 строка.
Шаг 2 теперь поясняет не только команду выгрузки, но и что именно выгружается:
- таблица шести выходов pg/outputs.tf (pg_host/pg_port/pg_username/pg_db_name/
pg_password/pg_ssl_mode) с указанием источника каждого;
- что terraform output -json кладёт объекты {sensitive, type, value}, а не голые
значения, поэтому в apps/locals.tf обращение идёт через .value;
- таблица соответствия: выход pg/ -> переменная окружения в Flask/Node.js/Lucee
(PGHOST/PGPORT/PGUSER/PGPASSWORD/PGDATABASE/PGSSLMODE, у Lucee ещё testds_* и DATABASE_URL).
Все факты сверены чтением файлов: pg/outputs.tf, apps/locals.tf, apps/flask.tf,
apps/nodejs.tf, apps/lucee.tf.
В разделе «Как это устроено» первая строка говорила только про destroy,
про изменения (apply) не было ни слова. Теперь явно: apply и destroy
в apps/ меняют только приложения, apply и destroy в pg/ — только базу.
Проверено: чтением файла после правки.
Убрано «(разделение ответственности, decoupling)» — это про модули кода, не про
состояния Terraform. Написано прямо: два отдельных файла состояния.
Добавлен факт, который был скрыт: связь pg -> apps идёт через apps/creds.json,
после смены хоста или пароля файл нужно обновить и повторить apply в apps/.
Проверено: чтением файла после правки.
HISTORY/README.md:
- назначение архива и приказ владельца документировать всё, включая ошибки;
- соглашения: имя файла YYYY-MM-DD_<тема>.md, нумерация папок шагом 10 как в NOTES/,
куда писать новую запись, почему диалоги с LLM держатся авторскими подпапками;
- таблица «папка -> о чём -> сколько файлов» (75 файлов);
- по каждому файлу строка с темой: 10_reviews (2), 20_releases (8), 30_provider (6),
40_generator (3), 50_docs (9), 60_stands (7), 70_infra (4), 90_llm (36:
gemini 2, OPUS 17, SONNET 17);
- помечены ⛔ четыре файла Opus от 2026-09-22 («ложный путь», отменено 2026-09-24);
- раздел «Известные особенности»: упоминания несуществующих 3006_0.md/3006_1.md
и ссылка на старый внешний репозиторий tf_registry/HISTORY/HOWTO-UPLOAD.md;
- раздел «Реорганизация»: перенос 2026-10-02 и путь к резервной копии.
Проверено: все 75 файлов с диска присутствуют в таблицах README, лишних нет
(кроме намеренно упомянутого несуществующего имени), все ссылки-папки существуют.
Перенос в тематические папки сломал бы все ссылки, поэтому обновлены пути:
- HISTORY/OPUS/ -> HISTORY/90_llm/OPUS/, HISTORY/SONNET/ -> HISTORY/90_llm/SONNET/;
- 15 целевых файлов из корня получили свой тематический префикс
(HISTORY/<файл>.md -> HISTORY/<папка>/<файл>.md) — в 33 файлах репозитория.
Затронуто вне HISTORY: README.md, VERSIONS.md, HOW_TO/DEVOPS_BUILD_PIPELINE.md,
NOTES/README.md, NOTES/10_plans/, NOTES/20_prompts/, NOTES/30_analysis/,
NOTES/40_chat_summaries/, docs/curated/{crud,postgres}, docs/help/dev-reference/,
docs/ops/TESTING.md.
Проверки после правки:
- ссылок вида HISTORY/<дата> без тематической папки не осталось;
- все пути HISTORY/*.md из markdown-ссылок существуют (кроме трёх упоминаний,
которые не были файлами и до переноса: HISTORY/90_llm/OPUS/3006_1.md,
3006_0.md — планировавшиеся имена в старых транскриптах,
и HISTORY/HOWTO-UPLOAD.md — ссылка на старый внешний репозиторий tf_registry);
- ссылки по «голому» имени внутри 90_llm/OPUS/ остались корректными (соседние файлы).
Было: 41 файл в корне HISTORY/ + авторские папки OPUS/ и SONNET/ (34 файла).
Стало — тематическая нумерация в стиле NOTES/ (10_, 20_, …):
10_reviews/ ревью кода и разборы от LLM (2)
20_releases/ заливки версий в реестр, чистки реестра, нумерация версий (8)
30_provider/ ядро провайдера: архитектура, модификаторы, UUID, nested (6)
40_generator/ генератор YAML/спеки, формат MAN (3)
50_docs/ пайплайн документации, навигация, публикация, хостинг S3 (9)
60_stands/ стенды и примеры: CRUD, FullPipe, Штурвал, TEST_STAND (7)
70_infra/ реестр, API Gateway, DDoS-Guard, VPN/213, зеркала (4)
90_llm/ диалоги и промпты с LLM вне тематики: OPUS/, SONNET/, gemini/ (34)
OPUS/ и SONNET/ перенесены как есть в 90_llm/ — чтобы не рвать пары
«бриф → ответ» внутри диалогов. Все переносы — через git mv (история сохранена).
Перед правкой: TMP/backup_2026-10-02/HISTORY_before_restructure.tar.gz.
Перекрёстные ссылки обновляются следующим коммитом.
Новый файл HISTORY/2026-10-02_s3_static_website_docs_hosting.md:
- итог живой проверки: у Nubes включён static website на Ceph RGW (Squid),
сайт целиком работает из S3 без ВМ; незакрыт только домен/TLS (принадлежит Nubes);
- единственное изменение состояния: PUT Bucket website (IndexDocument=index.html)
на бакете terraform-registry + команда отката; статус — оставлено, решения владельца нет;
- найдено уже настроенным у Nubes: NoSuchWebsiteConfiguration до PUT (значит API есть),
wildcard DNS *.s3-website.msk-1.ngcloud.ru -> 89.169.61.167, валидный TLS,
порт 80 закрыт, bucket policy PublicReadGetObject (Principal *);
- проверки: анонимные 200 с размерами, совпадающими с index.html (148758/139835/150021),
фактическая раскладка ключей docs/{nubes,nubes-dev,nubes-test}/nubes/…,
объектный эндпоинт каталоги не умеет (403) — резолвинг только на website-эндпоинте;
- зафиксирована моя ошибка: 403 приходили на НЕСУЩЕСТВУЮЩИЙ ключ docs/nubes/index.html;
уроки — сначала list-objects-v2, потом URL; сверять размеры и проверять анонимно+подписанно;
- побочные находки: list-buckets видит бакеты других тенантов; в secrets/.s3cfg_registry
лежат чужие ключи (tazet@narod.ru, ntazetdinov@nubes.ru);
- версии развития V0 (213+nginx) -> V1 (website-эндпоинт, проверена) -> V2 (origin их фронта),
отклонённые V3a/V3b/V3c и чек-лист дальнейших изменений.
- VERSIONS.md: новые sha256 всех трёх сборок;
- HISTORY: разбор бага (Computed-атрибут оставался unknown в ветках усыновления),
что правилось в 64328ab и 93784e4, проверки до заливки, а также зафиксированы
ошибки исполнителя (правки без разрешения, лишняя перегенерация, неверная
оценка в первом ревью).
По итогам код-ревью (коммит 64328ab):
- ResolveUserPasswordFromVault теперь возвращает и текст предупреждения: если пароль
прочитать не удалось (недоступен API/Vault, пустое имя, нет записи), в выводе apply
появляется Warning. Раньше поле молча становилось null и причина была невидима.
Отсутствие секретов у родителя ошибкой не считается (для части сервисов это норма).
- В шаблоне подресурса заполнение вынесено в одно замыкание applyPassword(),
вызываемое перед каждым resp.State.Set в Create (4 сохранения — 4 вызова).
Убирает четыре одинаковые строки и снижает риск забыть новую ветку выхода.
- Тест проверяет: замыкание есть, предупреждение есть, и вызовов applyPassword()
не меньше, чем сохранений состояния в Create.
Проверено: generated/test/go/90_postgres_user_resource.go — 4 State.Set, 4 вызова
(плюс одно упоминание в комментарии); go test ./... ok; go build ./internal/... и
полная сборка провайдера во временной копии с новым generated — чисто.
Баг (воспроизведён на 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.
Repinoid