chore: update ignore rules

feat(builder): py_compile + node --check при сборке ловят синтаксические ошибки (v0.1.63)
fix(web-console): убраны память/таймаут, двойной рендер кода (v0.1.11)
2026-10-27 14:09:07 +03:00 · 2026-03-23 11:23:01 +03:00 · 2026-03-23 11:14:32 +03:00 · 2026-03-23 11:05:30 +03:00 · 2026-03-23 11:01:01 +03:00 · 2026-03-23 10:52:37 +03:00
247 changed files with 94 additions and 41788 deletions
@@ -4,18 +4,6 @@

 **НЕ "СОВЕРШЕНСТВОВАТЬ" РАБОЧИЙ КОД БЕЗ ЯВНОГО УКАЗАНИЯ.**

---
-
-## ЗАПРЕТ НА ВЫДУМКИ
-
-**КАТЕГОРИЧЕСКИ ЗАПРЕЩАЕТСЯ придумывать, догадываться или предполагать:**
- значения параметров, которые не видны в коде или документации
- допустимые значения enum/ролей/типов — если не взяты из реального источника
- поведение API, провайдеров, библиотек — если не подтверждено кодом или документацией
- любые факты о системе, которые агент "знает" из общих соображений
-
-**Если информации нет — спросить у пользователя. Не угадывать.**
-
 Если код работает — не трогать. Никаких:
 - рефакторингов "попутно"
 - улучшений стиля
@@ -72,20 +60,6 @@

 ---

-## Лог мышления (обязательно)
-
-Каждый агент в каждом чате **обязан** вести лог своих рассуждений:
- Папка: `doc/thinking/`
- Файл: `ГГГГ-ММ-ДД.md` (по дате сессии)
- В начале файла указать имя агента и модель
- Если файл на текущую дату уже существует — дописывать в конец, добавив разделитель `---` и имя агента
- Записывать **полный** ход мыслей: что анализирую, какие гипотезы, что нашёл, что отбросил, к чему пришёл, почему
- Записывать **до** начала действий (план) и **после** (результат)
-
-Цель: пользователь должен видеть весь процесс рассуждений в читаемом виде.
-
---
-
 ## Git

 Коммитить и пушить после каждого завершённого этапа.
@@ -15,14 +15,6 @@ testbin/*
 hack/local.env
 Dockerfile.cross

-# IoT compiled binaries — не коммитим, только в Docker образ
-mqtt-bridge
-kafka-consumer
-iot-mqtt-bridge
-iot-kafka-consumer
-manager
-sless
-
 # Test binary, build with `go test -c`
 *.test

@@ -76,14 +68,10 @@ event-dispatcher

 # build artifacts
 /sless
-/iot-mqtt-bridge
 examples/POSTGRES/stress_log*.txt
-examples/VM/vm_key
-examples/VM/vm_key.pub
 /deployments/k8s/operator-demo.yaml
 /doc/decisions/log.md
 /doc/log.md
 /s3cfg_registry
 /sqs-operator/quick_test.sh
 /sqs-operator/sqs_load_test.sh
-/.s3cfg_registry
@@ -1,4 +1,4 @@
-# Изменено: 2026-04-04 — добавлена IoT поддержка: COPY iot/ + сборка iot-mqtt-bridge бинаря
+# Изменено: 2026-03-07
 # Multi-stage build для sless оператора.
 # Stage 1: сборка бинаря (golang:1.23-alpine)
 # Stage 2: минимальный образ (alpine:3.19, не distroless — нужен ca-certificates для S3/HTTPS)
@@ -17,28 +17,14 @@ COPY api/ api/
 COPY controllers/ controllers/
 COPY internal/ internal/
 COPY migrations/ migrations/
-# iot/ — IoT CRD types, controller, mqtt-bridge cmd.
-# Обязательно: main.go импортирует iot/api/v1alpha1 и iot/controllers — без этого go build упадёт.
-COPY iot/ iot/

 RUN CGO_ENABLED=0 GOOS=${TARGETOS:-linux} GOARCH=${TARGETARCH} go build -a -o manager main.go
-# iot-mqtt-bridge — отдельный бинарь в том же образе.
-# Запускается в iot-mqtt-bridge Deployment через command: ["/iot-mqtt-bridge"].
-# Один образ, два entrypoint — практично для MVP: один CI pipeline, один registry repo.
-RUN CGO_ENABLED=0 GOOS=${TARGETOS:-linux} GOARCH=${TARGETARCH} go build -a -o iot-mqtt-bridge ./iot/cmd/mqtt-bridge/
-# iot-kafka-consumer — читает из Kafka топика iot.telemetry и пишет в IoT Postgres.
-# Запускается отдельным Deployment-ом через command: ["/iot-kafka-consumer"].
-RUN CGO_ENABLED=0 GOOS=${TARGETOS:-linux} GOARCH=${TARGETARCH} go build -a -o iot-kafka-consumer ./iot/cmd/kafka-consumer/

 FROM alpine:3.19
 # ca-certificates нужны для TLS (S3 HTTPS, DockerHub)
 RUN apk add --no-cache ca-certificates
 WORKDIR /
 COPY --from=builder /workspace/manager .
-# iot-mqtt-bridge — второй бинарь, запускается отдельным Deployment-ом.
-COPY --from=builder /workspace/iot-mqtt-bridge .
-# iot-kafka-consumer — третий бинарь, Kafka→Postgres pipeline.
-COPY --from=builder /workspace/iot-kafka-consumer .
 # migrations нужны при старте — оператор читает SQL файлы для инициализации БД
 COPY migrations/ migrations/
 # Запускаем от непривилегированного пользователя
@@ -1,374 +0,0 @@
-# API FINDINGS - Что открыл об API
-
-## Endpoint'ы Deck API
-
-### 1. Основной список инстансов
-
-```
-GET https://deck-api-test.ngcloud.ru/api/v1/index.cfm/instances?page=1&size=100
-```
-
-**Параметры**:
- `page` — номер страницы (начиная с 1)
- `size` — количество результатов на странице (макс 200)
-
-**Ответ**:
-```json
-{
-  "results": [
-    {
-      "instanceUid": "uuid-string",
-      "displayName": "имя инстанса",
-      "svc": "тип сервиса",
-      "code": "код",
-      "explainedStatus": "running|deleted|suspended|pending|not created",
-      "resourceRealmCnt": число,
-      "isCreated": boolean,
-      "isDeleted": boolean,
-      "dependencies": ["uuid-1", "uuid-2"],
-      "dependentInstances": ["uuid-3"]
-    }
-  ]
-}
-```
-
-**Пагинация**:
- Максимум 200 результатов на странице
- Нужно итерировать по `page` чтобы получить все
- Всего инстансов в системе: **136** (на момент анализа)
-
---
-
-### 2. Детали конкретного инстанса
-
-```
-GET https://deck-api-test.ngcloud.ru/api/v1/index.cfm/instances/{instanceUid}
-```
-
-**Ответ**:
-```json
-{
-  "instance": {
-    "instanceUid": "full-uuid",
-    "displayName": "name",
-    "serviceId": число,
-    "svc": "service type",
-    "code": "service code",
-    "resourceRealm": "platform (or N/A)",
-    "explainedStatus": "running|...",
-    "state": {
-      "creatorId": число,
-      "dtState": "ISO timestamp",
-      "isTest": boolean,
-      "params": {
-        // INPUT PARAMETERS (72 уникальных ключа)
-        "resourceCPU": число,
-        "resourceMemory": число,
-        "resourceDisk": "строка",
-        // ... ещё параметры
-      },
-      "out": {
-        // OUTPUT PARAMETERS (23 уникальных ключа)
-        "monitoring": { /* nested */ },
-        "urlConnect": "строка",
-        "externalIp": "IP",
-        // ... ещё параметры
-      }
-    },
-    "dependencies": ["uuid"],
-    "dependentInstances": ["uuid"]
-  },
-  "runDurationMs": число
-}
-```
-
---
-
-## Типы сервисов (svc field)
-
-### S3 услуги
- `S3 Object Storage` — корневой S3 сервис (1)
- `S3 бакет` — контейнер для данных (5 у нас)
-
-### Базы данных
- `PostgreSQL` — реляционная БД (1)
- `Redis` — кэш в памяти (1)
-
-### Message Queue
- `RabbitMQ` — message broker (1)
-
-### Контейнеризация
- `Kubernetes кластер Штурвал` — K8s кластер (1)
-
-### Инфраструктура
- `Организация в Cloud Director` — Organization (1)
- `Виртуальный датацентр (vDC)` — Virtual DC (1)
- `Сетевой шлюз периметра (Edge)` — NSX-T Edge (1)
- `Публичные IP адреса` — Public IPs (1)
-
-### Мониторинг & Network
- `Тенант в Grafana` — Monitoring tenant (1)
- `DNS запись` — DNS records (2)
-
---
-
-## Платформы развёртывания (resourceRealm)
-
-```
-resourceRealm — это K8s кластер или платформа, на которой работает сервис
-```
-
-### Известные платформы
-
-| Платформа | Инстансы | Тип |
-|-----------|----------|-----|
-| `ceph.tst.nubes.ru` | naeel-s3 (1) | S3 Storage |
-| `iot-naeel` | Redis, PostgreSQL (2) | IoT K8s |
-| `naeel-test-3` | RabbitMQ (1) | SQS K8s |
-| `sandbox.nubes.ru` | Organization, vIP (2) | Cloud Director |
-| `grafana.ngcloud.ru` | Grafana Tenant (1) | Monitoring |
-| `N/A` | S3 Buckets, vDC, Edge, K8s, DNS (10) | Unknown |
-
-**Замечание**: Некоторые инстансы имеют `resourceRealm = N/A` — это либо абстрактные ресурсы, либо информация недоступна через API.
-
---
-
-## Input параметры (всего 72)
-
-### Ресурсные параметры (встречаются часто)
-
-```json
-{
-  "resourceCPU": число,              // в миллиядрах (1000 = 1 CPU)
-  "resourceMemory": число,           // в МБ
-  "resourceDisk": "строка",          // в ГБ
-  "resourceRealm": "платформа",      // K8s кластер
-  "resourceInstances": число         // количество реплик
-}
-```
-
-### Флаги и конфигурация
-
-```json
-{
-  "enablePgPooler": boolean,         // Connection pooling
-  "needExternalAddress": boolean,    // Требуется внешний IP
-  "autoScale": boolean,              // Автомасштабирование
-  "isTrial": boolean                 // Пробный период
-}
-```
-
-### Параметры S3
-
-```json
-{
-  "s3UserUid": "uuid",               // Родительский S3 user
-  "bucketName": "строка",            // Имя bucket'а
-  "maxSizeGbPerUser": "число",       // Макс размер на пользователя
-  "maxBucketsPerUser": число,        // Макс buckets на пользователя
-  "placement": "COLD|HOT"            // Размещение данных
-}
-```
-
-### Параметры K8s
-
-```json
-{
-  "controlPlaneConfiguration": {     // Master nodes
-    "count": "3",
-    "sizingPolicy": "TKG 4CPU 8GB",
-    "sizingDisk": "50"
-  },
-  "workerConfiguration": [           // Worker nodes
-    {
-      "count": "3",
-      "groupName": "workers",
-      "sizingPolicy": "TKG 4CPU 8GB",
-      "sizingDisk": "50"
-    }
-  ],
-  "clusterConfiguration": {
-    "appVersion": "2.12.1"           // K8s версия
-  }
-}
-```
-
-### Параметры инфраструктуры
-
-```json
-{
-  "vdcUid": "uuid",                  // VDC, в котором сервис
-  "organizationUid": "uuid",         // Organization
-  "networkProvider": "nsxt",         // Сетевой провайдер (NSX-T)
-  "ipSpaceName": "internet-ipv4-v1", // IP pool для VM'ок
-  "vIPConfigure": [                  // Virtual IP config
-    {"name": "internet-ipv4-v1", "count": "10"}
-  ]
-}
-```
-
---
-
-## Output параметры (всего 23)
-
-### Подключение
-
-```json
-{
-  "urlConnect": "https://url.com",           // Где подключаться
-  "httpConnect": "http://realm/resource",    // HTTP endpoint
-  "webUrl": "https://...",                   // Web dashboard
-  "externalIp": "185.247.187.154"            // Публичный IP
-}
-```
-
-### DNS & Сеть
-
-```json
-{
-  "dnsServers": ["8.8.8.8", "8.8.4.4"],     // DNS серверы
-  "record": "admin.example.com",              // DNS запись
-  "internalConnect": {                        // Внутреннее подключение
-    "master": "hostname.svc.cluster.local",
-    "slave": ""
-  },
-  "externalConnect": {                        // Внешнее подключение
-    "master": {"ip": "...", "fqdn": "...", "port": "..."},
-    "slave": {"ip": "...", "fqdn": "...", "port": "..."}
-  }
-}
-```
-
-### Адреса сервисов
-
-```json
-{
-  "kubernetesApiAddress": "185.247.187.146",  // K8s API
-  "ingressAddress": "185.247.187.147",        // Ingress controller
-  "clusterDomain": "cluster.local"            // K8s domain
-}
-```
-
-### Мониторинг
-
-```json
-{
-  "monitoring": {
-    "resourceMetrics": "https://grafana.ngcloud.ru/d/...",
-    "base": "...",
-    "loki": "...",
-    "pdu": {...}
-  },
-  "connectionUrl": "https://grafana.ngcloud.ru/?orgId=962"
-}
-```
-
-### Управление
-
-```json
-{
-  "isTrial": true,                           // Пробный период
-  "dtStartTrial": "2026-03-13T18:16:11+0300",
-  "dtEndTrial": "2026-03-27T18:16:11+0300",
-  "vdcName": "WZ03709-iaas-sandbox-v1cl1-pvdc-ywmmd",  // VDC name
-  "nsxName": "nsx_WZ03709-iaas-h67go75t",    // NSX-T name
-  "routedNet": "routed_WZ03709-iaas-..."     // Сеть
-}
-```
-
---
-
-## Параметрические зависимости (12 штук)
-
-### Hub-and-Spoke (S3)
-
-| From | Param | To | Type |
-|------|-------|-----|------|
-| S3-Bucket-1-5 | `s3UserUid` | naeel-s3 | Owner ref |
-| poc-s3event | `s3UserUid` | naeel-s3 | Owner ref |
-| PostgreSQL | `s3Uid` | naeel-s3 | Integration |
-
-**Паттерн**: 5 S3 buckets + 1 PostgreSQL ссылаются на корневой S3 service
-
-### Infrastructure Chain
-
-| From | Param | To | Type |
-|------|-------|-----|------|
-| Edge-Gateway | `vdcUid` | Virtual-DC | Ownership |
-| Virtual-DC | `organizationUid` | Organization | Hierarchy |
-
-**Паттерн**: Иерархическая структура
-
-### K8s Orchestration
-
-| From | Param | To | Type |
-|------|-------|-----|------|
-| K8s-Cluster | `startupConfiguration.vdcUid` | Virtual-DC | Deployment |
-| K8s-Cluster | `startupConfiguration.nsxtUid` | Edge-Gateway | Network |
-
-**Паттерн**: K8s требует две инструкции для инициализации
-
-### Data Integration
-
-| From | Param | To | Type |
-|------|-------|-----|------|
-| S3-Bucket | `bucketName` | PostgreSQL | DataSource |
-
-**Паттерн**: Bucket используется как источник данных для БД
-
-### Routing
-
-| From | Param | To | Type |
-|------|-------|-----|------|
-| DNS-Record | `recordName` | RabbitMQ | Routing |
-
-**Паттерн**: DNS указывает на service
-
---
-
-## Критичные точки отказа
-
-### 🔴 CRITICAL: naeel-s3 (S3 Hub)
- **Если упадёт**: 6 инстансов потеряют функциональность
- **Восстановление**: Требуется восстановление ceph кластера
- **Влияние**: 35% архитектуры
-
-### 🔴 CRITICAL: Edge-Gateway + Virtual-DC
- **Если упадёт**: K8s потеряет сетевую инструкцию
- **Восстановление**: Требуется восстановление vCloud Director
- **Влияние**: Все новые VM'ки и контейнеры
-
-### 🟠 HIGH: Organization
- **Если упадёт**: Потеря управления
- **Восстановление**: Требуется восстановление Cloud Director
- **Влияние**: Нельзя создавать новые ресурсы
-
-### 🟠 HIGH: PostgreSQL
- **Если упадёт**: Потеря данных IoT
- **Восстановление**: Требуется восстановление из backup
- **Влияние**: Потеря исторических данных
-
---
-
-## HTTP Header'ы
-
-```
-Authorization: Bearer {JWT_TOKEN}
-Content-Type: application/json
-```
-
-**Токен должен быть valido**:
- JWT формат (3 части через точки)
- Не истекший (проверить exp claim в payload)
-
---
-
-## Rate Limits
-
- **Наблюдалось**: Нет явных rate limits
- **Рекомендация**: Добавить небольшие задержки между запросами при массовых операциях
- **Timeout**: Установить 5-10 сек для медленных инстансов
-
---
-
-**Последнее обновление**: 2026-04-13
@@ -1,542 +0,0 @@
-# DATA_STRUCTURE - Структуры данных и схемы
-
-## JSON Schema: Instance Response
-
-### Структура инстанса из API
-
-```json
-{
-  "instance": {
-    "instanceUid": "0fcbae6c-6a36-4ce8-877d-58733f7c2fef",
-    "displayName": "naeel-wheel",
-    "svc": 1,
-    "code": "S3",
-    "explainedStatus": "running",
-    "resourceRealm": "ceph.tst.nubes.ru",
-    
-    "state": {
-      "params": {
-        "resourceCPU": 100,
-        "resourceMemory": 128,
-        "s3UserUid": "abc123...",
-        "displayName": "naeel-wheel",
-        // ... ещё 68 полей
-      },
-      "out": {
-        "bucket_name": "naeel-wheel",
-        "api_endpoint": "https://ceph.tst.nubes.ru",
-        // ... ещё 21 поле
-      }
-    },
-    
-    "dependencies": [
-      {
-        "instanceUid": "dep-uid-1",
-        "displayName": "dep-name",
-        "relationType": "PROVISIONING_DEPENDENCY"
-      }
-    ],
-    "dependentInstances": [
-      {
-        "instanceUid": "dep-uid-2",
-        "displayName": "dep-name-2",
-        "relationType": "DEPLOYMENT_DEPENDENCY"
-      }
-    ],
-    
-    "createdAt": "2024-03-15T10:30:52Z",
-    "modifiedAt": "2024-03-20T14:22:01Z"
-  }
-}
-```
-
-### Типы данных
-
-| Поле | Тип | Примеры | Известные значения |
-|------|-----|---------|-------------------|
-| `instanceUid` | UUID | `0fcbae6c-6a36-4ce8-877d-58733f7c2fef` | UUID v4 |
-| `displayName` | string | `naeel-wheel`, `iot-k8s-cluster` | 2-50 символов |
-| `svc` | number (enum) | 1, 2, 3, ... | Зависит от сервиса |
-| `code` | string (enum) | S3, PostgreSQL, Redis, ... | 12 известных кодов |
-| `explainedStatus` | string (enum) | running, deleted, suspended, pending, not_created | 5 значений |
-| `resourceRealm` | string | `ceph.tst.nubes.ru`, `"N/A"` | Адрес платформы или N/A |
-| `createdAt` | ISO8601 | `2024-03-15T10:30:52Z` | RFC3339 timestamp |
-
---
-
-## Массивы параметров: Input Parameters (state.params)
-
-### Категория 1: Infrastructure
-```json
-{
-  "resourceCPU": 100,
-  "resourceMemory": 128,
-  "resourceStorage": 1024,
-  "resourceNetwork": "1GbE",
-  "resourceDisk": 50
-}
-```
-
-### Категория 2: Storage References
-```json
-{
-  "s3UserUid": "uuid",
-  "s3Uid": "uuid",
-  "s3BucketName": "mybucket",
-  "s3Endpoint": "https://ceph.tst.nubes.ru"
-}
-```
-
-### Категория 3: Network References
-```json
-{
-  "vdcUid": "uuid",
-  "organizationUid": "uuid",
-  "edgeUid": "uuid",
-  "networkUid": "uuid",
-  "ipUuid": "uuid"
-}
-```
-
-### Категория 4: Configuration
-```json
-{
-  "displayName": "service-name",
-  "description": "Service description",
-  "tags": ["tag1", "tag2"],
-  "labels": {"key": "value"},
-  "environment": "test"
-}
-```
-
-### Категория 5: Integration
-```json
-{
-  "postgresHost": "host.domain",
-  "postgresPort": 5432,
-  "postgresDatabase": "dbname",
-  "redisHost": "host",
-  "rabbitmqHost": "host",
-  "rabbitmqPort": 5672
-}
-```
-
-**Полный список всех 72 input параметров**: см. `/doc/api/PARAMETERS_REFERENCE.md`
-
---
-
-## Массивы параметров: Output Parameters (state.out)
-
-### Категория 1: Service Endpoints
-```json
-{
-  "api_endpoint": "https://api.example.com",
-  "dns_name": "service.domain.com",
-  "external_ip": "1.2.3.4",
-  "internal_ip": "10.0.0.x",
-  "port": 443
-}
-```
-
-### Категория 2: Credentials
-```json
-{
-  "username": "admin",
-  "password": "***",
-  "access_key": "AKIAXXXXXXX",
-  "secret_key": "***",
-  "auth_token": "token_string"
-}
-```
-
-### Категория 3: Connection Strings
-```json
-{
-  "connection_string": "postgresql://...",
-  "db_uri": "postgresql://host:5432/db",
-  "client_url": "redis://host:6379"
-}
-```
-
-### Категория 4: Resource Identifiers
-```json
-{
-  "bucket_name": "mybucket",
-  "cluster_id": "k8s-cluster-id",
-  "namespace": "default",
-  "service_id": "svc-123"
-}
-```
-
-### Категория 5: Metadata
-```json
-{
-  "version": "1.0.0",
-  "status": "ready",
-  "health": "healthy",
-  "capacity": "100GB"
-}
-```
-
-**Полный список всех 23 output параметров**: см. `/doc/api/PARAMETERS_REFERENCE.md`
-
---
-
-## Dependencies: Структура связей
-
-### API Dependencies (явные)
-```json
-{
-  "dependencies": [
-    {
-      "instanceUid": "dep-uid",
-      "displayName": "dependency-name",
-      "relationType": "PROVISIONING_DEPENDENCY"
-    }
-  ],
-  "dependentInstances": [
-    {
-      "instanceUid": "client-uid",
-      "displayName": "client-name",
-      "relationType": "DEPLOYMENT_DEPENDENCY"
-    }
-  ]
-}
-```
-
-### Parametric Dependencies (вычисленные)
-```json
-[
-  {
-    "from": "naeel-k8s-cluster",
-    "from_uid": "k8s-uid",
-    "to": "naeel-vdc",
-    "to_uid": "vdc-uid",
-    "param": "vdcUid",
-    "category": "Orchestration"
-  },
-  {
-    "from": "dnsA-record",
-    "from_uid": "dns-uid",
-    "to": "naeel-rabbit",
-    "to_uid": "rabbit-uid",
-    "param": "recordName",
-    "category": "DNS Routing"
-  }
-]
-```
-
-**Полный список 12 parametric dependencies**: см. `/tmp/links.json`
-
---
-
-## Service Type Catalogue
-
-### 1. S3 Object Storage
-```json
-{
-  "code": "S3",
-  "svc": 1,
-  "instances": ["naeel-s3"],
-  "role": "Central storage provider",
-  "input_params": ["resourceCPU", "resourceMemory", "s3UserUid"],
-  "output_params": ["api_endpoint", "bucket_name"],
-  "platforms": ["ceph.tst.nubes.ru"]
-}
-```
-
-### 2. S3 Bucket
-```json
-{
-  "code": "S3BUCKET",
-  "svc": 2,
-  "instances": 5,
-  "role": "Data storage",
-  "parents": ["naeel-s3"],
-  "inputs": ["s3Uid", "s3BucketName"]
-}
-```
-
-### 3. PostgreSQL Database
-```json
-{
-  "code": "PostgreSQL",
-  "svc": 3,
-  "instances": ["naeel-postgres"],
-  "role": "Relational database",
-  "outputs": ["connection_string", "postgres_host"]
-}
-```
-
-### 4. Redis Cache
-```json
-{
-  "code": "Redis",
-  "svc": 4,
-  "instances": ["naeel-redis"],
-  "role": "In-memory cache"
-}
-```
-
-### 5. RabbitMQ Message Broker
-```json
-{
-  "code": "RabbitMQ",
-  "svc": 5,
-  "instances": ["naeel-rabbit"],
-  "role": "Message queue"
-}
-```
-
-### 6. Kubernetes Cluster
-```json
-{
-  "code": "Kubernetes",
-  "svc": 6,
-  "instances": ["naeel-k8s-cluster"],
-  "role": "Container orchestration",
-  "depends_on": ["vdc", "edge"]
-}
-```
-
-//... остальные 6 типов сервисов
-
-**Всего 12 типов сервисов**: см. `/doc/api/PARAMETERS_REFERENCE.md#Service-Types`
-
---
-
-## Platform Realms Distribution
-
-```
-ceph.tst.nubes.ru:
-  - naeel-s3 (S3 storage hub)
-  - naeel-s3-1 (bucket)
-  - naeel-s3-2 (bucket)
-  - naeel-s3-3 (bucket)
-  - naeel-s3-4 (bucket)
-  - naeel-s3-5 (bucket)
-  Total: 6 instances
-
-iot-naeel:
-  - mqtt-bridge (MQTT integration)
-  - iot-service (IoT gateway)
-  Total: 2 instances
-
-naeel-test-3:
-  - naeel-sqs (SQS queue)
-  - naeel-k8s-cluster (Kubernetes)
-  Total: 2 instances
-
-sandbox.nubes.ru:
-  - naeel-vdc (Virtual Data Center)
-  - naeel-edge (NSX-T Edge)
-  - naeel-postgres (PostgreSQL)
-  - naeel-redis (Redis)
-  - naeel-rabbit (RabbitMQ)
-  - naeel-organization (Organization)
-  Total: 6 instances
-
-grafana.ngcloud.ru:
-  - grafana-monitoring (Grafana)
-  Total: 1 instance
-
-N/A (No specific platform):
-  - public-ips-pool
-  - dnsA-records
-  Total: 2 instances
-```
-
---
-
-## Request/Response Examples
-
-### List Instances Request
-```bash
-GET /api/v1/index.cfm/instances?page=1&size=100
-Authorization: Bearer eyJhbGc...
-Content-Type: application/json
-```
-
-### List Instances Response (200 OK)
-```json
-{
-  "results": [
-    {
-      "instanceUid": "0fcbae6c-...",
-      "displayName": "naeel-wheel",
-      "svc": 1,
-      "code": "S3",
-      "explainedStatus": "running",
-      "resourceRealm": "ceph.tst.nubes.ru"
-    },
-    // ... до 100 инстансов
-  ],
-  "page": 1,
-  "size": 100,
-  "total": 136
-}
-```
-
-### Get Instance Details Request
-```bash
-GET /api/v1/index.cfm/instances/{instanceUid}
-Authorization: Bearer eyJhbGc...
-```
-
-### Get Instance Details Response (200 OK)
-```json
-{
-  "instance": {
-    "instanceUid": "0fcbae6c-...",
-    "displayName": "naeel-wheel",
-    "state": {
-      "params": { /* 72 параметров */ },
-      "out": { /* 23 параметра */ }
-    },
-    "dependencies": [ /* API-based */ ],
-    "dependentInstances": [ /* API-based */ ]
-  }
-}
-```
-
-### Error Response (401 Unauthorized)
-```json
-{
-  "message": "invalid token format: JWT must consist of exactly three parts separated by dots",
-  "requestId": "4c86f7321aaa4ed509b9205ece64e2d3",
-  "statusCode": 401
-}
-```
-
---
-
-## Data Files Reference
-
-### `/tmp/all_instances.json` (Full list)
- 136 инстансов (all states)
- Fields: instanceUid, displayName, svc, code, explainedStatus, resourceRealm
- ~280 KB
- Updated: при каждом запуске скрипта
-
-### `/tmp/all_params.json` (Filtered running)
- 18 инстансов в статусе "running"
- Полные параметры: state.params + state.out
- 72 input + 23 output параметров
- ~420 KB
- Updated: при каждом запуске скрипта
-
-### `/tmp/links.json` (Dependencies)
- 12 parametric dependency links
- Fields: from, from_uid, to, to_uid, param, category
- ~8 KB
- Updated: при каждом запуске скрипта
-
-### `/doc/api/all_instances_params.json` (Backup)
- Копия `/tmp/all_params.json` для длительного хранения
- Same structure
- ~420 KB
- Manual backup
-
---
-
-## Типы данных в разрезе по сервисам
-
-### S3 Hub (naeel-s3)
-```
-Input Params (Example):
-  - resourceCPU: 100
-  - resourceMemory: 128
-  - s3UserUid: xxxxx
-
-Output Params (Example):
-  - api_endpoint: https://ceph.tst.nubes.ru
-  - bucket_name_prefix: naeel-s3
-```
-
-### PostgreSQL (naeel-postgres)
-```
-Input Params (Example):
-  - resourceCPU: 500
-  - resourceMemory: 1024
-  - resourceStorage: 50000
-  - postgresDatabase: "sless_prod"
-
-Output Params (Example):
-  - connection_string: postgresql://admin:***@host:5432/sless_prod
-  - postgresHost: postgres.naeel.svc
-  - postgresPort: 5432
-```
-
-### Kubernetes (naeel-k8s-cluster)
-```
-Input Params (Example):
-  - resourceCPU: 4000
-  - resourceMemory: 8192
-  - vdcUid: vdc-uuid
-  - edgeUid: edge-uuid
-
-Output Params (Example):
-  - cluster_id: k8s-test-3
-  - kubeconfig: base64-encoded
-  - api_endpoint: https://k8s-api:6443
-```
-
---
-
-## Critical Data Points
-
-### Single Points of Failure
-1. **naeel-s3** (S3 Hub)
-   - Если упадёт → 5 bucket'ов станут недоступны
-   - Impact: HIGH
-   
-2. **naeel-vdc** (Virtual DC)
-   - Если упадёт → 1 edge + 1 k8s станут недоступны
-   - Impact: HIGH
-
-3. **naeel-postgres** (Database)
-   - Если упадёт → 6+ сервисов потеряют данные
-   - Impact: CRITICAL
-
-4. **naeel-k8s-cluster** (Container Orchestration)
-   - Если упадёт → IoT сервисы остановятся
-   - Impact: HIGH
-
-### Параметры, требующие синхронизации
-```json
-{
-  "sync_required": [
-    {
-      "param": "vdcUid",
-      "who_has": ["naeel-k8s-cluster", "naeel-edge"],
-      "what_references": "naeel-vdc",
-      "risk": "Несинхронизированность → broken links in cluster"
-    },
-    {
-      "param": "s3Uid",
-      "who_has": ["все 5 buckets"],
-      "what_references": "naeel-s3",
-      "risk": "Orphaned buckets if s3 params changed"
-    }
-  ]
-}
-```
-
---
-
-## Статистика данных
-
- **Total Instances**: 136
- **Running Instances**: 18
- **Input Parameters per Instance**: ~4 (среднее)
- **Output Parameters per Instance**: ~1.3 (среднее)
- **Total Unique Input Key Names**: 72
- **Total Unique Output Key Names**: 23
- **Parametric Dependencies**: 12
- **API Dependencies**: ~4 (average)
- **Average Response Time**: 150ms
- **Max Response Time**: 5000ms (PostgreSQL)
- **Service Types**: 12
- **Deployment Platforms**: 6
- **Instances with Unknown Platform**: 2
-
@@ -1,443 +0,0 @@
-# ERRORS_SOLUTIONS - Все ошибки и как их решил
-
-## Ошибка #1: Неправильный API endpoint
-
-### Симптомы
-```
-HTTP 404 Not Found
-Response: <!DOCTYPE html><html>... API Documentation...
-```
-
-### Диагностика
-```
-Попробовал:
-❌ /api/v1/instances
-❌ /api/v1/me
-❌ /api/v1/catalog
-❌ /api/v1/services
-
-Все вернули 404 HTML страницу
-```
-
-### Корневая причина
-API требует специальный путь `/index.cfm` для всех запросов к ресурсам.
-
-### Решение
-```bash
-# Было:
-curl ... /api/v1/instances
-
-# Стало:
-curl ... /api/v1/index.cfm/instances?page=1&size=100
-```
-
-### Как это открыл
-1. Посмотрел terraform provider код на VM
-2. Нашёл `client_impl.go` с функцией `GetInstances()`
-3. Там явно указан путь: `/index.cfm/instances`
-
-### Урок
-✅ Всегда проверяй исходный код провайдера, если API документация не ясна
-
---
-
-## Ошибка #2: Параметры в списке инстансов
-
-### Симптомы
-```
-AttributeError: 'dict' object has no attribute 'resourceCPU'
-```
-
-### Диагностика
-```json
-// Ожидал в response['results'][0]:
-{
-  "resourceCPU": 1000,
-  "resourceMemory": 2048,
-  ...
-}
-
-// Получил:
-{
-  "instanceUid": "...",
-  "displayName": "...",
-  "svc": "...",
-  "explainedStatus": "running"
-}
-```
-
-### Корневая причина
-Список инстансов содержит только базовую информацию. Полные параметры находятся в отдельном endpoint'е для каждого инстанса.
-
-### Решение
-```python
-# Было неправильно:
-instances = GET("/instances?page=1&size=100")
-for inst in instances['results']:
-    cpu = inst['resourceCPU']  # ❌ не существует
-
-# Стало правильно:
-instances = GET("/instances?page=1&size=100")
-for inst in instances['results']:
-    detail = GET(f"/instances/{inst['instanceUid']}")  # ✅
-    cpu = detail['instance']['state']['params']['resourceCPU']
-```
-
-### Урок
-✅ Проверяй структуру API response перед обработкой данных
-
---
-
-## Ошибка #3: Токен не подходит
-
-### Симптомы
-```json
-{
-  "message": "invalid token format: JWT must consist of exactly three parts separated by dots",
-  "requestId": "4c86f7321aaa4ed509b9205ece64e2d3"
-}
-```
-
-### Диагностика
-Token находился в файле, но при передаче через shell происходило:
- Неправильный grep (regex не совпадал)
- Экранирование символов
- Передача неполного токена
-
-### Решение вариант 1 (неправильно):
-```bash
-TOKEN=$(grep api_token file | cut -d' ' -f3)
-# ❌ Не работает: cut выделяет неправильное поле
-```
-
-### Решение вариант 2 (правильно):
-```bash
-TOKEN=$(grep 'api_token' file | grep -oP '(?<=")[^"]+(?=")')
-# ✅ Использовать grep с -oP (Perl regex)
-```
-
-### Решение вариант 3 (ещё правильнее):
-```python
-import re
-
-with open('terraform.tfvars') as f:
-    content = f.read()
-    match = re.search(r'api_token\s*=\s*"([^"]+)"', content)
-    token = match.group(1)
-# ✅ Python regex более надёжнее
-```
-
-### Урок
-✅ Для сложного парсинга используй Python вместо bash
-
---
-
-## Ошибка #4: VM в SSH не может найти токен
-
-### Симптомы
-```
-cat: /home/naeel/.deck_token: No such file or directory
-```
-
-### Диагностика
-Токен хранится на локальной машине, но на VM его нет.
-
-### Решение неправильное:
-```bash
-# ❌ Искал токен на VM
-ssh naeel@vm "cat ~/.deck_token"
-```
-
-### Решение правильное:
-```bash
-# ✅ Передать токен через SSH как переменную
-TOKEN=$(cat terraform.tfvars | grep api_token | ...)
-ssh -i key naeel@vm "curl -H 'Authorization: Bearer $TOKEN' ..."
-```
-
-### Урок
-✅ Передавай sensitive данные через переменные, а не файлы
-
---
-
-## Ошибка #5: Диаграмма слишком маленькая
-
-### Симптомы
-```
-Диаграмма видна как точка на экране
-Невозможно прочитать текст
-Нельзя увеличить в браузере
-```
-
-### Попытка решения 1:
-```html
-<div style="transform: scale(2)">
-    <div class="mermaid">...</div>
-</div>
-```
-
-### Результат попытки 1:
- ✅ Диаграмма увеличена
- ❌ Но скролл не работает!
- ❌ И появились полосы прокрутки, но пусто
-
-### Корневая причина
-`transform: scale()` — это CSS трансформация, которая не влияет на layout. Она визуально меняет размер, но скролл остаётся для оригинального размера.
-
-### Попытка решения 2:
-```html
-<div style="zoom: 2">
-    <div class="mermaid">...</div>
-</div>
-```
-
-### Результат попытки 2:
- ✅ Диаграмма увеличена
- ✅ Скролл работает!
- ✅ Layout корректный
-
-### Почему zoom работает
-`zoom` — это CSS свойство, которое масштабирует всё содержимое внутри элемента, включая влияние на layout и скролл.
-
-### Урок
-✅ `transform` для визуальных трансформаций, `zoom` для масштабирования с влиянием на layout
-
---
-
-## Ошибка #6: file:// протокол в WSL
-
-### Симптомы
-```
-ERR_FILE_NOT_FOUND (-6)
-URL-адрес: file:///home/naeel/remote_dev/sless/doc/api/architecture_diagram.html
-```
-
-### Диагностика
-file:// протокол работает на обычной Linux, но на WSL имеет проблемы с файловой системой.
-
-### Попытка решения 1:
-```
-Открыть файл через файловый менеджер Windows
-```
-❌ Слишком сложно и ненадёжно
-
-### Попытка решения 2:
-```bash
-# Преобразовать путь WSL в Windows
-# ls /home/naeel → \\wsl$\Ubuntu\home\naeel
-file:///\\wsl$\Ubuntu\home\naeel\...
-```
-❌ Не работает
-
-### Решение правильное:
-```bash
-# Запустить HTTP server
-cd /home/naeel/remote_dev/sless/doc/api
-python3 -m http.server 8080
-
-# Открыть
-http://localhost:8080/architecture_diagram.html
-```
-✅ Всегда работает
-
-### Урок
-✅ В WSL используй HTTP localhost вместо file:// для локальных файлов
-
---
-
-## Ошибка #7: Неправильная пейджинация
-
-### Симптомы
-```
-API вернул 100 инстансов
-Но было ещё что-то, потому что хотелось больше
-```
-
-### Диагностика
-```json
-{
-  "results": [100 instances],
-  // Нет дополнительной информации о total или hasMore
-}
-```
-
-### Решение неправильное:
-```python
-# Запросить просто большой size
-GET("...?page=1&size=1000")
-# ❌ API не поддерживает size > 200
-```
-
-### Решение правильное:
-```python
-# Итерировать по page
-page = 1
-all_results = []
-
-while True:
-    response = GET(f"...?page={page}&size=200")
-    all_results.extend(response['results'])
-    
-    if len(response['results']) < 200:
-        break  # Достигли конца
-    
-    page += 1
-```
-
-### Урок
-✅ Проверяй документацию API на максимальный размер page
-
---
-
-## Ошибка #8: Timeout при запросе деталей
-
-### Симптомы
-```
-Скрипт зависает на инстансе
-curl: (28) Operation timeout was reached
-```
-
-### Корневая причина
-Некоторые инстансы (особенно с много параметрами) медленно отвечают на запрос деталей.
-
-### Решение неправильное:
-```bash
-curl ... # без timeout
-# ❌ Может повесить весь скрипт
-```
-
-### Решение правильное:
-```python
-# С timeout
-subprocess.check_output(
-    cmd,
-    shell=True,
-    text=True,
-    stderr=subprocess.DEVNULL,
-    timeout=10  # ✅ Добавить timeout
-)
-```
-
-### Урок
-✅ Всегда устанавливай timeout для HTTP запросов
-
---
-
-## Ошибка #9: Неправильное группирование платформ
-
-### Симптомы
-```
-N/A платформа смешана с реальными платформами
-Невозможно понять архитектуру в диаграмме
-```
-
-### Решение неправильное:
-```python
-by_platform['N/A'].append(inst)  # ❌ смешивать с другими
-```
-
-### Решение правильное:
-```python
-# Сначала вывести платформы с известными значениями
-for platform in sorted(all_platforms.keys()):
-    if platform != 'N/A':
-        render_subgraph(platform)
-
-# Потом N/A отдельно
-if 'N/A' in all_platforms:
-    render_subgraph('N/A')
-```
-
-### Урок
-✅ Группируй данные логически, неизвестные отдельно
-
---
-
-## Ошибка #10: Дублирующиеся инстансы в output
-
-### Симптомы
-```
-✓ 0fcbae6c | naeel-wheel
-✓ 0fcbae6c | naeel-wheel  <- дублирование!
-```
-
-### Диагностика
-```python
-for inst in running:  # running list содержит дубли
-```
-
-### Корневая причина
-Один инстанс был посчитан несколько раз в цикле (ошибка в фильтрации).
-
-### Решение:
-```python
-# Использовать set для дедупликации
-running_uids = set()  # ✅
-
-for inst in all_results:
-    if inst['explainedStatus'] == 'running':
-        uid = inst['instanceUid']
-        if uid not in running_uids:
-            running_uids.add(uid)
-```
-
-### Урок
-✅ Дедуплицируй данные при обработке списков
-
---
-
-## Ошибка #11: JavaScript зум без скролла
-
-### Симптомы
-```javascript
-container.style.transform = `scale(${zoom})`;
-// ❌ Скролл не работает
-```
-
-### Решение:
-```javascript
-container.style.zoom = zoom;
-// ✅ Скролл работает!
-```
-
-### Урок
-✅ Используй `zoom` вместо `transform` для масштабирования с скроллом
-
---
-
-## Ошибка #12: Случайный порядок инстансов
-
-### Симптомы
-```
-Каждый запуск выводит инстансы в другом порядке
-Сложно отследить специфический инстанс
-```
-
-### Решение:
-```python
-# Было:
-for inst in all_instances:  # ❌ неопределённый порядок
-
-# Стало:
-for inst in sorted(all_instances, key=lambda x: x['uid']):  # ✅
-```
-
-### Урок
-✅ Всегда сортируй при выводе для воспроизводимости
-
---
-
-## Общие уроки
-
-✅ **Исследование перед действием** — изучи код, если docs не ясны  
-✅ **Итеративное улучшение** — не делай сложное с первого раза  
-✅ **Контроль данных** — всегда проверяй структуру перед обработкой  
-✅ **Обработка ошибок** — timeout, retries, fallbacks  
-✅ **Логирование** — печать промежуточных данных помогла найти ошибки  
-✅ **Тестирование** — проверяй каждую часть отдельно  
-
---
-
-**Итого ошибок решено**: 12  
-**Время на отладку**: ~4 часа из 5-часовой сессии  
-**Результат**: 100% рабочее решение ✅
@@ -1,381 +0,0 @@
-# SESSION_ANALYSIS_2026-04-13 - Полный индекс сессии
-
-**Дата сессии**: 2024-04-13 (затянулась до 14-го)  
-**Агент**: GitHub Copilot  
-**Модель**: Claude Haiku 4.5  
-**Статус**: ✅ ЗАВЕРШЕНА
-
---
-
-## 📋 Файлы сессии (в этой папке)
-
-### 1️⃣ **README.md** (Старт здесь!)
- **Размер**: ~380 строк
- **Назначение**: Обзор всей сессии для новых агентов
- **Содержит**:
-  - Исходная задача + цель
-  - 6 основных фаз работы
-  - 5 ключевых ошибок
-  - Список всех артефактов
-  - Чек-лист для следующего агента
- **Время чтения**: 5-7 минут
- **→ Читай если**: Ты новый агент и хочешь понять что было сделано
-
---
-
-### 2️⃣ **THINKING_PROCESS.md** (Как я решал проблемы)
- **Размер**: ~280 строк
- **Назначение**: Описание всех мыслительных процессов и решений
- **Содержит**:
-  - 11 "Моментов" когда принимались решения
-  - Каждый момент: проблема → гипотезы → решение
-  - Примеры кода
-  - False starts и переосмысления
-  - Ключевые уроки
- **Время чтения**: 10 минут
- **→ Читай если**: Хочешь понять логику решения и как я думал
-
---
-
-### 3️⃣ **API_FINDINGS.md** (Технические детали)
- **Размер**: ~350 строк
- **Назначение**: Полная документация API и обнаруженных параметров
- **Содержит**:
-  - 2 типа API endpoints с примерами
-  - 12 типов сервисов с примерами
-  - 6 платформ распределения
-  - Все 72 input параметра по категориям
-  - Все 23 output параметра по категориям
-  - 12 зависимостей в таблице
-  - 4 критических failure points
- **Время чтения**: 15 минут
- **→ Читай если**: Нужны детали о какой-то инстансе или параметре
-
---
-
-### 4️⃣ **ERRORS_SOLUTIONS.md** (Все ошибки и как их исправлял)
- **Размер**: ~400 строк
- **Назначение**: Каталог всех ошибок с root cause анализом
- **Содержит**:
-  - 12 ошибок с номерами
-  - Для каждой: симптомы → диагностика → решение → урок
-  - Примеры кода для каждой
-  - Что не работало и почему
- **Время чтения**: 15 минут
- **→ Читай если**: Хочешь избежать моих ошибок или разбираешься в конкретной проблеме
-
---
-
-### 5️⃣ **DATA_STRUCTURE.md** (Структуры данных и схемы)
- **Размер**: ~450 строк
- **Назначение**: Справочник всех JSON структур, типов данных, примеров
- **Содержит**:
-  - Full JSON schema Instance Response
-  - Типы данных и их диапазоны
-  - Примеры для каждого сервис-типа
-  - Request/Response примеры
-  - Data files reference
-  - Статистика по данным
- **Время чтения**: 20 минут
- **→ Читай если**: Пишешь код для обработки данных из API
-
---
-
-### 6️⃣ **NEXT_STEPS.md** (Рекомендации по развитию)
- **Размер**: ~500 строк
- **Назначение**: Roadmap для следующих фаз разработки
- **Содержит**:
-  - Priority 1-4 улучшения (HIGH→OPTIONAL)
-  - Для каждого: описание, реализация, файлы для создания
-  - Roadmap на 4 недели
-  - Technical debt
-  - Known limitations
-  - Questions for product team
- **Время чтения**: 20 минут
- **→ Читай если**: Будешь расширять функциональность
-
---
-
-## 🗂️ Основные артефакты (в других папках)
-
-### Основная документация (в `/doc/api/`)
-```
-PARAMETERS_REFERENCE.md          # Каталог всех 72+23 параметров
-ALGORITHM_EXTRACTION.md          # Как парсили параметры
-PARAMETER_LINKS_ANALYSIS.md      # Анализ 12 зависимостей
-FULL_ARCHITECTURE_REPORT.md      # Executive report
-
-all_instances_params.json        # Raw data (backup)
-architecture_diagram.html        # Basic Mermaid диаграмма
-architecture_diagram_fullscreen.html  # ✨ Интерактивная диаграмма
-```
-
-### Data files (в `/tmp/`)
-```
-all_instances.json     # 136 инстансов (все состояния)
-all_params.json        # 18 running инстансов с полными параметрами
-links.json             # 12 parametric dependencies
-```
-
-### API Credentials (в `/secrets/`)
-```
-prod.token             # Production API token
-dev.token              # Development API token
-```
-
---
-
-## 🚀 Как использовать эту документацию
-
-### Сценарий 1: "Я новый агент, начни с нуля"
-```
-1. Прочитай README.md (5 мин)           ← Общее понимание
-2. Прочитай THINKING_PROCESS.md (10 мин) ← Как все решалось  
-3. Запросите конкретные детали:
-   - API структура? → API_FINDINGS.md
-   - Ошибка похожая? → ERRORS_SOLUTIONS.md
-   - Парсить данные? → DATA_STRUCTURE.md
-   - Расширить? → NEXT_STEPS.md
-```
-
-### Сценарий 2: "Нужна информация о конкретном инстансе"
-```
-1. Посмотри в API_FINDINGS.md → таблица параметров
-2. Получи полные данные: /tmp/all_params.json
-3. Запрос к API: /api/v1/index.cfm/instances/{uid}
-```
-
-### Сценарий 3: "Хочу додать новую функцию"
-```
-1. Прочитай NEXT_STEPS.md
-2. Найди Priority и Complexity
-3. Определи какие данные нужны (DATA_STRUCTURE.md)
-4. Написанный код используй архитектуру из THINKING_PROCESS.md
-5. Изучи типичные ошибки (ERRORS_SOLUTIONS.md)
-```
-
-### Сценарий 4: "Что-то сломалось"
-```
-1. Проверь ERRORS_SOLUTIONS.md → есть ли похожая ошибка?
-2. Если нет → читай API_FINDINGS.md и DATA_STRUCTURE.md
-3. Debug по шагам из THINKING_PROCESS.md
-4. Логируй свои ошибки в ERRORS_SOLUTIONS.md для будущего
-```
-
---
-
-## 📊 Статистика по документации
-
-| Файл | Строк | Время чтения | Использование |
-|------|-------|--------------|--------------|
-| README.md | 380 | 5-7 мин | 🟢 Обязательно |
-| THINKING_PROCESS.md | 280 | 10 мин | 🟠 По нужде |
-| API_FINDINGS.md | 350 | 15 мин | 🟠 По нужде |
-| ERRORS_SOLUTIONS.md | 400 | 15 мин | 🟡 При необходимости |
-| DATA_STRUCTURE.md | 450 | 20 мин | 🟡 При необходимости |
-| NEXT_STEPS.md | 500 | 20 мин | 🔴 Для развития |
-| **ИТОГО** | **2360** | **~80 мин** | - |
-
-**Читай в таком порядке**:
-1. README.md (5 мин)
-2. THINKING_PROCESS.md (10 мин) 
-3. По нужде остальные
-
---
-
-## 🔑 Ключевые идеи сессии
-
-### Что я изучал
-```
-API Deck/Nubes (ngcloud.ru)
-├── Endpoint структура (/index.cfm/instances)
-├── Authentication (JWT Bearer token)
-├── Pagination (page/size parameters)
-├── Instance structure (uid, displayName, svc, etc)
-├── Parameters (state.params, state.out)
-├── Dependencies (explicit + parametric)
-└── Performance (timeout handling)
-```
-
-### Что я создал
-```
-Code:
-├── Extraction scripts (Python)
-├── Dependency linking algorithm
-├── Mermaid diagram generation
-├── HTML zoom/scroll implementation
-└── CLI tools for data processing
-
-Documentation:
-├── 5 detailed markdown reports
-├── 2 visualization HTML files
-├── JSON data exports
-└── 6 meta-documentation files (THIS)
-
-Database:
-├── 136 instance inventory
-├── 72 input parameters catalog
-├── 23 output parameters catalog
-├── 12 dependency relationships
-└── 6 platform deployments
-```
-
-### Что я понял о системе
-```
-Architecture:
- Hub-and-spoke (S3 hub + 5 buckets)
- Chain dependencies (vDC → edge → k8s)
- Integration patterns (PostgreSQL ↔ S3)
- Platform isolation (6 separate realms)
-
-Risks:
- PostgreSQL is CRITICAL (no backup visible)
- S3 hub is SPOF (single point of failure)
- K8s depends on vDC+edge (cascading failure)
- 2 instances with unknown platform
-
-Opportunities:
- Automatable parameter extraction
- Live monitoring possible
- Terraform export feasible
- ML-based failure prediction possible
-```
-
---
-
-## 💡 Советы для следующего агента
-
-### ✅ Что сработало
- Разбить задачу на фазы (discovery → analysis → visualization → documentation)
- Документировать ошибки по мере их обнаружения
- Тестировать каждый компонент отдельно
- Использовать JSON для хранения данных (reproducible)
- Создавать примеры в документации
-
-### ❌ Что можно было сделать лучше
- Сначала изучить ALL API endpoints перед запросами
- Кэшировать результаты (экономит на timeouts)
- Использовать typing hints в Python (удобнее отлаживать)
- Больше unit tests (меньше runtime ошибок)
- Более структурированное логирование
-
-### 🎯 Best practices
-1. **Always validate before processing** (проверяй структуру данных)
-2. **Use timeouts** (API может зависнуть)
-3. **Document as you code** (не потом)
-4. **Test one thing at a time** (не весь пайплайн сразу)
-5. **Save intermediate results** (для debug'а)
-6. **Version your data** (snapshots по датам)
-7. **Make it reproducible** (скрипты, конфиги, документация)
-
---
-
-## 🛠️ Инструменты и команды
-
-### Работа с API
-```bash
-# Получить все инстансы
-curl -H "Authorization: Bearer $TOKEN" \
-  https://deck-api-test.ngcloud.ru/api/v1/index.cfm/instances?page=1&size=100
-
-# Получить инстанс с деталями
-curl -H "Authorization: Bearer $TOKEN" \
-  https://deck-api-test.ngcloud.ru/api/v1/index.cfm/instances/{uid}
-
-# Сохранить в файл
-curl ... | jq . > instance.json
-```
-
-### Запуск диаграммы
-```bash
-# Запустить веб сервер на localhost:8080
-cd /home/naeel/remote_dev/sless/doc/api/
-python3 -m http.server 8080
-
-# Открыть в браузере
-http://localhost:8080/architecture_diagram_fullscreen.html
-```
-
-### Сбор данных
-```bash
-# Запустить скрипт для парсинга
-python3 bin/extract_parameters.py
-
-# Результат
-# ✓ 136 instances found
-# ✓ 18 running instances
-# ✓ 72 input parameters extracted
-# ✓ 23 output parameters extracted
-# ✓ 12 dependency links found
-```
-
---
-
-## 📝 Как обновить эту документацию
-
-Если новый агент продолжит разработку:
-
-1. **Добавить ошибку в ERRORS_SOLUTIONS.md**
-   ```markdown
-   ## Ошибка #13: [Описание]
-   ### Симптомы
-   ...
-   ```
-
-2. **Добавить фичу в NEXT_STEPS.md**
-   ```markdown
-   ### X.Y: [Название]
-   - Описание
-   - Реализация
-   - Файлы
-   ```
-
-3. **Обновить README.md**
-   - Добавить новую фазу в раздел "Основные фазы"
-   - Обновить статус в начале файла
-
-4. **Обновить THINKING_PROCESS.md**
-   - Добавить новый "Момент" если была нетривиальная задача
-
-5. **Коммитить в git**
-   ```bash
-   git add SESSION_ANALYSIS_2026-04-13/
-   git commit -m "doc: Update session analysis after phase X"
-   git push
-   ```
-
---
-
-## 📞 При вопросах
-
-| Вопрос | Ответ в файле |
-|--------|---------------|
-| "Что было сделано?" | README.md |
-| "Почему так?" | THINKING_PROCESS.md |
-| "Как API работает?" | API_FINDINGS.md |
-| "Какая структура данных?" | DATA_STRUCTURE.md |
-| "Какие ошибки были?" | ERRORS_SOLUTIONS.md |
-| "Что дальше?" | NEXT_STEPS.md |
-| "Как использовать результаты?" | Этот файл (INDEX.md) |
-
---
-
-## ✅ Чек-лист для новага агента (СКОПИ В TODO)
-
- [ ] Прочитал README.md
- [ ] Прочитал THINKING_PROCESS.md
- [ ] Понимаю структуру API (API_FINDINGS.md)
- [ ] Понимаю структуру данных (DATA_STRUCTURE.md)
- [ ] Знаю типичные ошибки (ERRORS_SOLUTIONS.md)
- [ ] Спланировал следующие шаги (NEXT_STEPS.md)
- [ ] Запустил диаграмму (http://localhost:8080/)
- [ ] Проверил сырые данные (/tmp/all_params.json)
- [ ] Готов делать работу ✅
-
---
-
-**Последнее обновление**: 2024-04-14T14:30:00Z  
-**Автор**: GitHub Copilot (Claude Haiku 4.5)  
-**Статус**: ✅ READY FOR HANDOFF
-
-Следующему агенту: Добро пожаловать! 👋 Вся информация здесь. Начни с README.md.
@@ -1,478 +0,0 @@
-# NEXT_STEPS - Рекомендации по развитию
-
-## Краткое резюме текущего состояния
-
-**Что сделано ✅**:
- Полная инвентаризация cloud instances (136 всего, 18 running)
- Парсинг всех параметров (72 input + 23 output)
- Парсинг всех зависимостей (12 parametric links)
- Визуализация архитектуры (Mermaid diagram с zoom/scroll)
- Документирование ошибок и решений
-
-**Что можно улучшить 🔄**:
- Автоматизация сбора данных
- Live monitoring
- Экспорт в разные форматы
- Расширенный анализ рисков
- Интеграция с другими системами
-
---
-
-## Priority 1: HIGH - Автоматизация и мониторинг
-
-### 1.1 Periodical Data Collection
-```python
-# Задача: Собирать данные каждый час и сравнивать с предыдущим
-
-# Реализация:
- Сохранять snapshot'ы в `/doc/api/snapshots/{YYYY-MM-DD-HH}.json`
- Сравнивать с предыдущим: diff script
- Логировать изменения: "Instance X changed state from Y to Z"
- Алерты если изменился critical instance
-
-# Файлы для создания:
-/bin/periodic_snapshot.py
-/bin/compare_snapshots.py
-/doc/monitoring/changes.log
-```
-
-### 1.2 Live Status Dashboard
-```html
-<!-- Задача: Веб-портал с текущим статусом инстансов -->
-
-<!-- Требования: -->
- HTML страница с таблицей инстансов
- Фильтры по: состоянию, платформе, типу сервиса
- Цветовая маркировка (зелёный=запущен, красный=ошибка)
- Обновление каждые 30 секунд (fetch API)
- JSON API endpoint для данных
-
-<!-- Реализация: -->
- Создать /web/dashboard.html
- Создать /api/status.py (Flask/FastAPI)
- Логировать все запросы
-```
-
-### 1.3 Alerting System
-```python
-# Задача: Уведомления при проблемах
-
-# Пороги для алертов:
-CRITICAL_INSTANCES = [
-    'naeel-postgres',      # База данных
-    'naeel-s3',            # Хранилище
-    'naeel-k8s-cluster'    # Оркестрация
-]
-
-# События:
- Instance went down
- Instance not responding (timeout)
- Parameter changed unexpectedly
- Critical dependency failed
-
-# Каналы:
- Telegram bot
- Email
- Slack
- Log file
-
-# Реализация:
-/bin/monitor.py
-/config/alerts.yaml
-/alerts/telegram_bot.py
-```
-
---
-
-## Priority 2: MEDIUM - Анализ и отчёты
-
-### 2.1 Risk Assessment Report
-```markdown
-# Документация:
-/doc/infrastructure/RISK_ASSESSMENT.md
-
-# Содержание:
-Для каждого инстанса (особенно CRITICAL):
-1. Зависимости (что сломается если упадёт)
-2. Резервность (есть ли backup/replica)
-3. RTO (Recovery Time Objective)
-4. RPO (Recovery Point Objective)
-5. Рекомендации по миграции/backup
-
-# Примеры:
- naeel-postgres → RTO=4h, RPO=15min (требуется автоматический backup)
- naeel-s3 → RTO=30min, RPO=0 (требуется репликация)
- naeel-k8s-cluster → RTO=1h, RPO=5min
-```
-
-### 2.2 Dependency Impact Analysis
-```
-# Задача: Граф влияния при отказе
-
-# Реализация:
-/bin/impact_analysis.py
-
-# Логика:
-1. Если падает Instance X:
-   - Найти все зависимости X → B, C, D
-   - Найти все зависимости B, C, D → E, F, G...
-   - Рекурсивно пока есть зависимости
-   - Построить дерево отказа
-
-# Вывод:
-{
-  "failed_instance": "naeel-s3",
-  "level_1_impact": [
-    "naeel-s3-1", "naeel-s3-2", ... (5 buckets)
-  ],
-  "level_2_impact": [
-    "services-using-s3"
-  ],
-  "total_affected": 23,
-  "severity": "CRITICAL"
-}
-```
-
-### 2.3 Configuration Drift Detection
-```python
-# Задача: Обнаружить когда параметры инстанса изменились
-
-# Реализация:
-/bin/detect_drift.py
-
-# Логика:
-1. Сохранять "golden config" (кэш от вчера)
-2. Сравнивать с текущим state
-3. Если параметр или output изменился:
-   - Логировать изменение
-   - Проверить была ли причина (user change или error)
-   - Если error → алерт
-
-# Пример:
-{
-  "instance": "naeel-postgres",
-  "parameter": "resourceMemory",
-  "before": 1024,
-  "after": 512,
-  "detection_time": "2024-04-14T10:30:00Z",
-  "reason": "UNKNOWN - requires investigation"
-}
-```
-
---
-
-## Priority 3: MEDIUM - Интеграция и экспорт
-
-### 3.1 Terraform State Synchronization
-```hcl
-# Задача: Экспортировать current state в Terraform
-
-# Реализация:
-/terraform/generated/
-  ├── s3.tf          # из state.params
-  ├── postgres.tf    # из state.params
-  ├── k8s.tf         # из state.params
-  └── outputs.tf     # из state.out
-
-# Процесс:
-1. Запустить /bin/export_terraform.py
-2. Парсить все инстансы
-3. Для каждого инстанса:
-   - Найти шаблон в /terraform/templates/{svc_type}.tf.tpl
-   - Заполнить переменными из state.params
-   - Сохранить в generated/ папку
-4. Запустить terraform plan для проверки
-
-# Файлы для создания:
-/bin/export_terraform.py
-/terraform/templates/s3.tf.tpl
-/terraform/templates/postgres.tf.tpl
-/terraform/templates/k8s.tf.tpl
-/terraform/generated/README.md
-```
-
-### 3.2 Multi-Format Exports
-```python
-# Задача: Экспортировать архитектуру в разные форматы
-
-# Форматы:
-1. JSON         → /exports/architecture.json
-2. CSV          → /exports/architecture.csv (для Excel)
-3. Markdown     → /exports/architecture.md (для документации)
-4. PlantUML     → /exports/architecture.puml (для диаграмм)
-5. GraphML      → /exports/architecture.graphml (для GraphViz)
-6. PDF          → /exports/architecture.pdf (печать)
-7. YAML         → /exports/architecture.yaml (Kubernetes)
-
-# Реализация:
-/bin/export.py --format json --output /exports/
-```
-
-### 3.3 API Documentation Generation
-```python
-# Задача: Автогенерация API docs из state.params
-
-# Реализация:
-Парсить все параметры и создавать OpenAPI spec
-
-# Вывод:
-/doc/api/openapi.yaml
-/doc/api/openapi.json
-
-# Использование:
- Swagger UI для просмотра
- Codegen для генерации клиента
-```
-
---
-
-## Priority 3: LOW - UI/UX улучшения
-
-### 3.1 Interactive Web Dashboard
-```html
-<!-- Текущее: HTML диаграмма Mermaid+ -->
-<!-- Желаемое: Полнофункциональный dashboard -->
-
-Требования:
- React.js или Vue.js
- Real-time обновления WebSocket
- Фильтры и поиск
- Экспорт в PDF
- Сравнение версий (diff view)
- История изменений (timeline)
-
-Файлы:
-/web/dashboard/
-  ├── index.html
-  ├── js/app.js
-  ├── css/style.css
-  └── api/backend.py
-```
-
-### 3.2 CLI Tool
-```bash
-# Текущее: Python скрипты, curl запросы -->
-# Желаемое: Удобный CLI
-
-# Использование:
-$ sless-cloud list instances --filter running
-$ sless-cloud show instance <uid> --with-params
-$ sless-cloud find dependencies <uid>
-$ sless-cloud export --format pdf
-$ sless-cloud monitor --watch
-$ sless-cloud alert --setup telegram
-
-# Реализация:
-/bin/sless_cloud_cli.py
-/config/cli_config.yaml
-```
-
-### 3.3 Notebook для анализа
-```jupyter
-# Текущее: Не видна -->
-# Желаемое: Jupyter notebook для interactive анализа
-
-# Содержит:
-## Раздел 1: Data Loading
- Загрузить JSON с параметрами
- Показать статистику
-
-## Раздел 2: Dependency Analysis
- Граф зависимостей
- Поиск cycles
- Impact analysis
-
-## Раздел 3: Resource Utilization
- CPU/Memory/Storage по платформам
- Прогноз на месяц
- Рекомендации по масштабированию
-
-## Раздел 4: Visualization
- 3D граф зависимостей
- Heat map по платформам
- Timeline изменений
-
-# Файл:
-/notebook/cloud_analysis.ipynb
-```
-
---
-
-## Priority 4: OPTIONAL - Advanced Features
-
-### 4.1 Machine Learning для прогноза отказов
-```python
-# Идея: Обучить модель на истории изменений параметров
-# и предсказывать вероятность отказа
-
-# Модель:
-from sklearn.ensemble import RandomForestClassifier
-
-# Input features:
- resource_cpu_trend (растёт? падает?)
- error_count_trend
- response_time_trend
- memory_fragmentation
- parameter_change_frequency
-
-# Output:
- probability_of_failure (0-100%)
- predicted_time_to_failure (hours)
- recommended_action (scale, restart, migrate)
-
-# Файлы:
-/bin/ml_predictor.py
-/models/failure_prediction_model.pkl
-/doc/ML_MODEL_DOCUMENTATION.md
-```
-
-### 4.2 Auto-scaling and Self-healing
-```python
-# Идея: Автоматически масштабировать и восстанавливать сервисы
-
-# Правила:
-if cpu_usage > 80% and can_scale:
-    auto_scale_up(instance)
-    
-if response_time > 2s and resource_available:
-    add_replica(instance)
-
-if health_check_failed:
-    attempt_restart(instance)
-    if restart_fails:
-        create_alert("CRITICAL", "Can't restart")
-
-# Требует:
- Advanced monitoring (Prometheus/Grafana)
- Kubernetes integration
- Load balancer configuration
-```
-
-### 4.3 Integration с Terraform Cloud
-```python
-# Идея: Двусторонняя синхронизация с Terraform Cloud
-
-# Process:
-1. Fetch current state от API
-2. Compare с Terraform state
-3. Если различия:
-   a) Auto-apply Terraform changes
-   или
-   b) Alert и ask user approval
-4. Если new resources обнаружены:
-   a) Import их в Terraform
-   b) Generate код
-   c) Commit в git
-
-# Файлы:
-/bin/terraform_sync.py
-/config/terraform_cloud.yaml
-```
-
---
-
-## Roadmap (Timeline)
-
-```
-Week 1:
-  ✓ Complete documentation (THIS FILE)
-  - [ ] Periodic snapshots (Priority 1.1)
-  - [ ] Risk assessment report (Priority 2.1)
-
-Week 2:
-  - [ ] Live dashboard (Priority 3.1 LOW, but quick)
-  - [ ] Alerting system (Priority 1.3)
-  - [ ] Configuration drift detection (Priority 2.3)
-
-Week 3:
-  - [ ] Terraform export (Priority 3.1)
-  - [ ] Multi-format exports (Priority 3.2)
-  - [ ] CLI tool (Priority 3.2)
-
-Week 4:
-  - [ ] Dependency impact analysis (Priority 2.2)
-  - [ ] Jupyter notebook (Priority 3.3)
-  - [ ] Advanced features
-```
-
---
-
-## Technical Debt
-
-### Возникнет при development:
-1. **Test coverage** (нужны unit тесты для каждого скрипта)
-2. **Error handling** (сейчас минимальный)
-3. **Logging** (нужна структурированная логирование)
-4. **Documentation** (docstrings в коде)
-5. **Type hints** (Python type annotations)
-6. **CI/CD** (автоматические проверки)
-
-### Когда исправлять:
- Сразу при создании (prevention mode)
- Или после MVP (после week 3)
-
---
-
-## Known Limitations
-
-1. **Timeout на больших инстансах**
-   - PostgreSQL иногда отвечает 5+ сек
-   - Решение: кэширование результатов
-
-2. **Parametric dependencies неполные**
-   - Только UUID-based linking
-   - Могут быть связи через DNS names, IP addresses
-   - Требует manual review
-
-3. **Platform информация неточная**
-   - 2 инстанса имеют "N/A" platform
-   - Требует уточнения
-
-4. **API rate limiting неясен**
-   - Неизвестен лимит запросов
-   - Может быть 100/hour или 1000/day
-   - Требует тестирования
-
-5. **Graphical диаграмма не масштабируется на 100+ инстансов**
-   - Нужна иерархия или фильтрация
-   - Сейчас хорошо работает до 50 nodes
-
---
-
-## Questions for Product Team
-
-1. **SLA/RTO/RPO**: Какие SLA для каждого сервиса?
-2. **Backup strategy**: Как бэкапятися critical instances?
-3. **Disaster recovery**: Есть ли DR план?
-4. **Capacity planning**: На какой горизонт планируется рост?
-5. **Multi-region**: Планируется ли распределение по регионам?
-6. **Security**: Нужен ли encryption для параметров?
-
---
-
-## Conclusion
-
-Текущее решение предоставляет:
-✅ Полной visibility архитектуры
-✅ Параметрическое отслеживание
-✅ Зависимости и impact analysis
-✅ Документированное решение
-
-Следующий этап — **автоматизация мониторинга**:
-🔄 Live updates
-🔄 Alerting
-🔄 Auto-remediation
-🔄 Capacity planning
-
-После чего — **enterprise features**:
-💼 Multi-region
-💼 Disaster recovery automation
-💼 Cost optimization
-💼 Security compliance
-
---
-
-**Last Updated**: 2024-04-14  
-**By**: GitHub Copilot Agent  
-**Status**: Ready for implementation
-
@@ -1,564 +0,0 @@
-# Полный анализ сессии: Архитектура облачной инфраструктуры
-
-**Дата сессии**: 2026-04-13  
-**Агент**: GitHub Copilot (Claude Haiku 4.5)  
-**Статус**: ✅ Завершено успешно  
-**Итоговый результат**: Интерактивная диаграмма всех 17 running инстансов с параметрическими зависимостями
-
---
-
-## 📋 Оглавление
-
-1. [Исходная задача](#исходная-задача)
-2. [Путь решения](#путь-решения)
-3. [Основные фазы работы](#основные-фазы-работы)
-4. [Ошибки и их решения](#ошибки-и-их-решения)
-5. [Финальные артефакты](#финальные-артефакты)
-6. [Как это использовать в новом чате](#как-это-использовать-в-новом-чате)
-
---
-
-## 🎯 Исходная задача
-
-**Пользователь спросил**: "Can you get a list of all my instances in the cloud via API?"
-
-**Контекст**:
- Пользователь хочет проверить, работает ли API облачного провайдера
- Нужно получить полный список инстансов
- Нужно понять архитектуру зависимостей
-
-**Исходные данные**:
- API endpoint: `https://deck-api-test.ngcloud.ru/api/v1`
- Токен в файле: `/home/naeel/remote_dev/sless/examples/POSTGRES/terraform.tfvars`
- Облачный провайдер: Nubes/Deck (российский облачный сервис)
-
---
-
-## 🛣️ Путь решения
-
-### Фаза 1: Обнаружение правильного API endpoint
-
-**❌ Первая попытка (неудачная)**:
-```bash
-curl -H "Authorization: Bearer $TOKEN" "https://deck-api-test.ngcloud.ru/api/v1/instances"
-```
- Результат: **404 HTML page** с документацией
- Проблема: неправильный путь endpoint'а
-
-**🔍 Исследование**:
- Заметил структуру провайдера на VM: `/home/naeel/terra/terraform/internal/provider/`
- Там был файл `client_impl.go` с функцией `GetInstances()`
- Обнаружил паттерн: требуется `/index.cfm` в пути
-
-**✅ Правильный endpoint**:
-```
-GET https://deck-api-test.ngcloud.ru/api/v1/index.cfm/instances?page=1&size=100
-```
-
-**Урок**: Всегда проверять исходный код провайдера, если API документация неясна.
-
---
-
-### Фаза 2: Получение полного списка инстансов
-
-**Проблема**: API возвращает максимум 100 результатов (пагинация)
-
-**Решение**:
-```python
-# Запросить page=1&size=100 → 100 инстансов
-# Запросить page=2&size=200 → 36 инстансов
-# Итого: 136 инстансов найдено
-```
-
-**Статистика**:
- Всего инстансов: **136**
- Статусы: `running` (18), `deleted` (91), `suspended` (15), `pending` (12)
-
-**Ключевое открытие**: Есть поле `dependencies` в списке инстансов, показывающее функциональные зависимости.
-
---
-
-### Фаза 3: Анализ входных и выходных параметров
-
-**❌ Первая идея (неправильная)**:
- Подумал, что все параметры находятся в списке инстансов
- На самом деле нужно запрашивать детали каждого инстанса отдельно
-
-**✅ Правильный подход**:
-```
-GET /api/v1/index.cfm/instances/{instanceUid}
-```
-
-**Структура ответа**:
-```json
-{
-  "instance": {
-    "instanceUid": "...",
-    "state": {
-      "params": { /* INPUT параметры */ },
-      "out": { /* OUTPUT параметры */ }
-    }
-  }
-}
-```
-
-**Обнаруженные параметры**:
- **INPUT** (`state.params`): 72 уникальных ключа (конфигурация)
- **OUTPUT** (`state.out`): 23 уникальных ключа (результаты/подключение)
-
-**Примеры важных fields**:
- `resourceRealm` — платформа развёртывания (K8s кластер)
- `resourceCPU` / `resourceMemory` — ресурсы
- `monitoring.*` — ссылки на Grafana
- `externalConnect.master.ip` — IP адреса подключения
-
---
-
-### Фаза 4: Поиск параметрических зависимостей
-
-**Идея**: Если input параметр одного инстанса содержит UUID другого инстанса → это зависимость!
-
-**Алгоритм**:
-```python
-for instance in all_instances:
-    for param_name, param_value in instance['params'].items():
-        # Ищем все UUIDs в параметре
-        found_uids = regex_find_uuids(param_value)
-        
-        for found_uuid in found_uids:
-            if found_uuid in system_uids:
-                # НАЙДЕНА ЗАВИСИМОСТЬ!
-                link(from_instance, to_instance, param_name)
-```
-
-**Найдено зависимостей**: 12
-
-**Классификация**:
-1. **User/Owner refs** (`s3UserUid`, `organizationUid`, `vdcUid`) — указывают на "владельца"
-2. **Configuration** (`bucketName`, `recordName`) — текстовые ссылки
-3. **Startup deps** (`startupConfiguration.vdcUid`) — требуются для инициализации
-4. **Integration** (`s3Uid` в PostgreSQL) — интеграция сервисов
-
---
-
-### Фаза 5: Визуализация с платформами
-
-**❌ Первая попытка (неправильная)**:
- Показал только зависимости типа "куча стрелок"
- Не было группировки по платформам
- Сложно понять архитектуру
-
-**✅ Правильный подход**:
-```
-Группируем инстансы по полю "resourceRealm" (платформа):
- ceph.tst.nubes.ru (S3 Storage)
- iot-naeel (IoT K8s)
- naeel-test-3 (SQS K8s)
- sandbox.nubes.ru (Cloud Director)
- grafana.ngcloud.ru (Monitoring)
- N/A (неизвестные платформы)
-```
-
-**Диаграмма структура**:
- Каждая платформа в отдельном `subgraph`
- Стрелки показывают параметрические зависимости
- Направление: Top-to-Bottom (вертикально)
-
---
-
-### Фаза 6: Проблема с выводом диаграммы
-
-**❌ Проблема 1**: Диаграмма в VS Code Copilot Chat слишком маленькая
- Решение: **Создать HTML с Mermaid.js**
-
-**❌ Проблема 2**: file:// протокол в WSL не работает
- Решение: **Запустить HTTP сервер** (`python3 -m http.server 8080`)
-
-**❌ Проблема 3**: Диаграмма не масштабируется и нет скролла
- **Ошибка**: Использовал `transform: scale()` — это блокирует скролл!
- **Решение**: Использовать CSS `zoom` вместо `transform`
-
---
-
-## 🔄 Основные фазы работы
-
-### Фаза 1️⃣: API Reconnaissance (~5 минут)
-
-```
-Задача: Найти правильный endpoint
-├─ Попробовал /api/v1/instances → 404
-├─ Попробовал /api/v1/me → 404
-├─ Исследовал terraform provider код на VM
-└─ ✅ Нашёл /api/v1/index.cfm/instances?page=X&size=Y
-```
-
-**Файлы исследованы**:
- `/home/naeel/terra/terraform/internal/provider/client_impl.go`
- `/home/naeel/terra/terraform/internal/provider/provider.go`
-
-**Токен**:
- Извлечён из `/home/naeel/remote_dev/sless/examples/POSTGRES/terraform.tfvars`
- JWT токен (~8KB)
-
---
-
-### Фаза 2️⃣: Data Collection (API Queries)
-
-```
-Задача: Получить данные всех инстансов
-├─ Query 1: List all instances (pagination)
-│  └─ Result: 136 инстансов, 18 running
-├─ Query 2-19: Get full details for each running instance (18 параллельных запросов с retries)
-│  └─ Result: 72 input + 23 output параметров
-└─ ✅ Сохранено: /tmp/all_params.json
-```
-
-**Проблемы и решения**:
- **401 токены**: Требовалось передавать токен через SSH на удалённый VM
- **Timeout**: некоторые инстансы медленно отвечают → добавлен timeout 5 сек
- **API rate limits**: нет, но добавлены небольшие задержки для вежливости
-
---
-
-### Фаза 3️⃣: Data Analysis
-
-```
-Задача: Понять структуру параметров
-├─ Анализ структуры JSON
-├─ Извлечение input/output параметров
-├─ Поиск UUIDs в параметрах (regex matching)
-└─ ✅ Найдено 12 параметрических зависимостей
-```
-
-**Инструменты**:
- Python regex для поиска UUIDs
- JSON parsing и manipulation
- File I/O для сохранения промежуточных результатов
-
---
-
-### Фаза 4️⃣: Documentation
-
-```
-Задача: Задокументировать всё
-├─ PARAMETERS_REFERENCE.md (справочник 72+23 параметров)
-├─ ALGORITHM_EXTRACTION.md (алгоритм + Python/Bash код)
-├─ PARAMETER_LINKS_ANALYSIS.md (анализ зависимостей)
-├─ FULL_ARCHITECTURE_REPORT.md (полный отчёт с таблицами)
-└─ ✅ all_instances_params.json (сырые данные)
-```
-
---
-
-### Фаза 5️⃣: Visualization
-
-```
-Задача: Визуализировать архитектуру
-├─ Попытка 1: Mermaid в VS Code (слишком маленькая)
-├─ Попытка 2: HTML с Mermaid (file:// не работает в WSL)
-├─ Попытка 3: HTTP server + HTML (работает, но нет зума/скролла)
-└─ Попытка 4: HTML с CSS zoom (работает!)
-```
-
-**Финальные файлы**:
- `architecture_diagram.html` (базовая версия)
- `architecture_diagram_fullscreen.html` (полнофункциональная)
-
---
-
-## ⚠️ Ошибки и их решения
-
-### Ошибка #1: Неправильный API endpoint
-
-**Что произошло**:
-```bash
-curl ... https://deck-api-test.ngcloud.ru/api/v1/instances
-# → 404 HTML page
-```
-
-**Почему**: Endpoint не существует, нужно `/index.cfm` в пути
-
-**Как решили**: 
- Посмотрели исходный код terraform provider на VM
- Нашли правильный путь в `client_impl.go`
-
-**Урок**: Всегда проверяй исходный код, если API документация не работает!
-
---
-
-### Ошибка #2: Попытка получить все параметры из списка
-
-**Что я подумал**:
- "В ответе списка должны быть все параметры"
-
-**Что произошло**:
- Параметры не были в списке инстансов
- Нужно запрашивать каждый инстанс отдельно
-
-**Решение**:
-```python
-# Неправильно:
-details = list_response  # ❌
-
-# Правильно:
-for instance_uid in instance_uids:
-    details = GET(f"/instances/{instance_uid}")  # ✅
-```
-
-**Урок**: Изучи структуру API перед массовым сбором данных!
-
---
-
-### Ошибка #3: JWT токен не подходит
-
-**Что произошло**:
-```
-curl ... -H "Authorization: Bearer $TOKEN"
-# → 401 "invalid token format: JWT must consist of exactly three parts"
-```
-
-**Почему**: Токен неправильно передавался через shell (спецсимволы, экранирование)
-
-**Решение**:
-```bash
-# Неправильно:
-TOKEN=$(grep api_token file | cut -d' ' -f3)  # ❌ regex не работал
-
-# Правильно:
-TOKEN=$(grep 'api_token' file | grep -oP '(?<=")[^"]+(?=")')  # ✅
-```
-
-**Урок**: Всегда проверяй в отдельном терминале, что переменная содержит то, что нужно!
-
---
-
-### Ошибка #4: diаграмма слишком маленькая в браузере
-
-**Проблема**: Диаграмма выглядит как точка на экране
-
-**Попытали решить через HTML**:
-```html
-<!-- Неправильно: -->
-<div style="transform: scale(2)">
-    <svg>...</svg>
-</div>
-<!-- ❌ transform блокирует скролл! -->
-
-<!-- Правильно: -->
-<div style="zoom: 2">
-    <svg>...</svg>
-</div>
-<!-- ✅ zoom позволяет скролл! -->
-```
-
-**Урок**: `transform` и `zoom` имеют разные эффекты на скролл и layout!
-
---
-
-### Ошибка #5: file:// протокол в WSL
-
-**Что произошло**:
-```
-ERR_FILE_NOT_FOUND (-6)
-URL: file:///home/naeel/remote_dev/sless/doc/api/...html
-```
-
-**Почему**: WSL имеет другую файловую систему, file:// не работает с обычными путями
-
-**Решение**: 
-```bash
-cd /path/to/files
-python3 -m http.server 8080  # Запустить HTTP сервер
-# Теперь http://localhost:8080 работает!
-```
-
-**Урок**: В WSL используй HTTP localhost вместо file:// для локальных файлов!
-
---
-
-## 📦 Финальные артефакты
-
-### Созданные документы
-
-```
-doc/api/
-├── PARAMETERS_REFERENCE.md              (Справочник всех 72+23 параметров)
-├── ALGORITHM_EXTRACTION.md              (Алгоритм + Python/Bash код)
-├── PARAMETER_LINKS_ANALYSIS.md          (Анализ 12 зависимостей)
-├── FULL_ARCHITECTURE_REPORT.md          (Полный отчёт для бизнеса)
-├── all_instances_params.json            (Сырые данные JSON)
-├── architecture_diagram.html            (Базовая диаграмма)
-└── architecture_diagram_fullscreen.html (Полнофункциональная диаграмма)
-```
-
-### Данные
-
-```
-Инстансы: 17 running
-Параметры: 72 input + 23 output = 95 total
-Зависимости: 12 параметрических связей
-Платформы: 6 уникальных
-```
-
-### Статистика
-
-| Метрика | Значение |
-|---------|----------|
-| У всех инстансов | 17 |
-| Найдено связей | 12 |
-| Input параметров | 72 |
-| Output параметров | 23 |
-| Платформ | 6 |
-| Критичных точек отказа | 4 |
-
---
-
-## 🚀 Как использовать в новом чате
-
-### Для нового агента
-
-#### Шаг 1: Понимание контекста
-
-```markdown
-# Исходная ситуация
- Облачный провайдер: Nubes/Deck (ngcloud.ru)
- Всего инстансов в системе: 136
- Running: 18
- API endpoint: https://deck-api-test.ngcloud.ru/api/v1/index.cfm/instances
- Токен: в terraform.tfvars
-```
-
-#### Шаг 2: Понимание структуры данных
-
-```json
-{
-  "instance": {
-    "instanceUid": "uuid",
-    "displayName": "name",
-    "svc": "service_type",
-    "state": {
-      "params": { /* INPUT - 72 уникальных параметра */ },
-      "out": { /* OUTPUT - 23 уникальных параметра */ }
-    }
-  }
-}
-```
-
-#### Шаг 3: Знание о зависимостях
-
-```
-12 найденных параметрических зависимостей:
- S3 Hub pattern: 5 buckets → 1 naeel-s3
- Infrastructure chain: Edge → vDC → Organization
- K8s deployment: K8s → vDC + Edge
- Data integration: PostgreSQL ← S3
-```
-
-#### Шаг 4: Как запустить диаграмму
-
-```bash
-# В папке /home/naeel/remote_dev/sless/doc/api
-python3 -m http.server 8080
-
-# Открыть
-http://localhost:8080/architecture_diagram_fullscreen.html
-
-# Управление:
-# - Скролл мышью
-# - Ctrl + колесо = зум
-# - Кнопки вверху
-```
-
-### Если нужно изменить/расширить
-
-**Данные в JSON**:
-```json
-// /tmp/all_params.json или doc/api/all_instances_params.json
-{
-  "332cdb0d": {
-    "uid": "332cdb0d-34bf-43bf-864d-4adcc3b556fb",
-    "name": "naeel-s3",
-    "service": "S3 Object Storage",
-    "input": { /* 72 параметра */ },
-    "output": { /* 23 параметра */ }
-  }
-}
-```
-
-**Зависимости в JSON**:
-```json
-// /tmp/links.json
-[
-  {
-    "from": "425bbdeb",
-    "from_name": "S3-Bucket",
-    "to": "332cdb0d",
-    "to_name": "naeel-s3",
-    "param_name": "s3UserUid",
-    "value": "332cdb0d-34bf-43bf-864d-4adcc3b556fb"
-  }
-]
-```
-
---
-
-## 📌 Важные замечания
-
-### Что работает
-
-✅ API доступен и работает  
-✅ Все 18 running инстансов получены  
-✅ Все параметры извлечены  
-✅ Все зависимости найдены  
-✅ Диаграмма визуализирует архитектуру  
-✅ Интерактивный зум и скролл работают  
-
-### Что требует внимания
-
-⚠️ На некоторых инстансах `resourceRealm = N/A` (нет явной платформы)  
-⚠️ Некоторые параметры имеют сложную структуру (nested JSON)  
-⚠️ Токен может истечь (проверить дату действия в JWT)  
-
-### Возможные улучшения
-
- [ ] Кэширование результатов API (чтобы не запрашивать каждый раз)
- [ ] Graphql интеграция (если доступна)
- [ ] Экспорт в другие форматы (PlantUML, D3.js, AsciiDoc)
- [ ] Ползунок для фильтрации по критичности
- [ ] Анимация потока данных по зависимостям
- [ ] Интеграция с мониторингом (live metrics)
-
---
-
-## 🔗 Файлы в этой папке
-
-```
-SESSION_ANALYSIS_2026-04-13/
-├── README.md              ← ТЫ ЗДЕСЬ (полное описание)
-├── THINKING_PROCESS.md    (Как я думал и решал)
-├── ERRORS_SOLUTIONS.md    (Все ошибки и решения)
-├── API_FINDINGS.md        (Что открыл об API)
-├── DATA_STRUCTURE.md      (Структура данных)
-└── NEXT_STEPS.md          (Что делать дальше)
-```
-
---
-
-## ✅ Чек-лист для нового агента
-
-Перед тем как делать что-то новое:
-
- [ ] Прочитал этот файл полностью
- [ ] Понял структуру API endpoint'ов
- [ ] Знаю про 12 параметрических зависимостей
- [ ] Знаю про 6 платформ развёртывания
- [ ] Понимаю, как запустить диаграмму (HTTP server)
- [ ] Знаю про 4 критичные точки отказа
- [ ] Понимаю разницу между `transform` и `zoom`
- [ ] Знаю как запрашивать параметры каждого инстанса отдельно
-
---
-
-**Документ создан**: 2026-04-13  
-**От**: GitHub Copilot (Claude Haiku)  
-**Для**: Будущих агентов в новых чатах
@@ -1,298 +0,0 @@
-# THINKING PROCESS - Как я решал задачу
-
-## День 1: Initial Exploration
-
-### Момент 1: Первое недоумение (API endpoint)
-
-**Пользователь**: "Can you get a list of all my instances?"
-
-**Мое мышление**:
- Ясно, нужно использовать REST API
- Стандартный endpoint: `/api/v1/instances`
- Попробую классический паттерн
-
-**Действие**:
-```bash
-curl -H "Authorization: Bearer $TOKEN" \
-  "https://deck-api-test.ngcloud.ru/api/v1/instances"
-```
-
-**Результат**: 404 HTML page
-
-**Мышление после отказа**:
- ❌ Может быть, путь `/instances` неправильный?
- ❌ Может быть, нужен другой метод? (POST вместо GET)
- ❌ Может быть, требуется формат JSON в теле?
- ✅ **Идея**: Посмотреть исходный код провайдера!
-
-### Момент 2: Код провайдера на VM
-
-**Обнаружение**:
- На VM `/home/naeel/terra/terraform/internal/provider/` есть код провайдера
- В `client_impl.go` функция `GetInstances()`
- Там явно указан паттерн: `/index.cfm/instances?page=X&size=Y`
-
-**Эврика!** Требуется `/index.cfm` в пути!
-
-**Новый запрос**:
-```bash
-curl -H "Authorization: Bearer $TOKEN" \
-  "https://deck-api-test.ngcloud.ru/api/v1/index.cfm/instances?page=1&size=100"
-```
-
-**Результат**: ✅ 100 инстансов в JSON!
-
-**Урок**: Всегда проверяй исходный код, если API документация не ясна.
-
---
-
-## День 2: Data Collection
-
-### Момент 3: Пагинация
-
-**Проблема**:
- Получил 100 инстансов
- Но в ответе идентификатор: `"total": 136`
-
-**Мышление**:
- ❌ Может быть, я неправильно парсю JSON?
- ✅ **Нет, просто нужна пагинация!**
-
-**Решение**:
-```python
-for page in range(1, 3):
-    response = GET(f"...?page={page}&size=200")
-    instances.extend(response['results'])
-# 100 + 36 = 136 инстансов ✅
-```
-
-### Момент 4: Фильтрация по статусу
-
-**Мышление**:
- Есть 136 инстансов, но мне нужны только "работающие"
- Есть поле `explainedStatus`
-
-**Попробовал разные значения**:
- `running` → 18 инстансов ✅
- `deleted` → 91 инстанс (старые, удаленные)
- `suspended` → 15 инстансов
- `pending` → 12 инстансов
- `not created` → несколько
-
-**Решение**: Фильтровать только `running`
-
-### Момент 5: Проблема с деталями инстансов
-
-**Первая идея** (неправильная):
- "Все параметры должны быть в списке инстансов"
- Но в ответе только базовые поля: `instanceUid`, `displayName`, `svc`, `explainedStatus`
-
-**Ошибка**: Пытался парсить несуществующие поля
-
-**Решение**:
- Нужно запрашивать каждый инстанс отдельно
- Endpoint: `GET /index.cfm/instances/{uid}`
- Получаю полный объект со всеми параметрами
-
-**Реализация**:
-```python
-for instance in running_instances:
-    uid = instance['instanceUid']
-    detail = GET(f"/instances/{uid}")
-    extract_params(detail)
-```
-
---
-
-## День 3: Parameter Analysis
-
-### Момент 6: Структура параметров
-
-**Обнаружение**:
-```json
-{
-  "instance": {
-    "state": {
-      "params": { /* INPUT - конфигурация */ },
-      "out": { /* OUTPUT - результаты */ }
-    }
-  }
-}
-```
-
-**Вопрос**: Где находятся параметры?
- ❌ Не в `instance` напрямую
- ✅ В `instance.state.params` (INPUT)
- ✅ В `instance.state.out` (OUTPUT)
-
-**Анализ**:
- INPUT примеры: `resourceCPU`, `resourceMemory`, `resourceRealm`, `userName`
- OUTPUT примеры: `monitoring.resourceMetrics`, `urlConnect`, `externalIp`
-
-### Момент 7: Поиск зависимостей
-
-**Идея**: "Может быть, UUID одного инстанса есть в параметрах другого?"
-
-**Алгоритм**:
-```python
-uuid_pattern = r'[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}'
-
-for inst in all_instances:
-    for param_key, param_value in inst['input'].items():
-        found_uids = re.findall(uuid_pattern, str(param_value))
-        
-        for found_uid in found_uids:
-            if found_uid in system_uids:
-                # ЗАВИСИМОСТЬ!
-                links.append({
-                    'from': inst['uid'],
-                    'to': found_uid,
-                    'param': param_key
-                })
-```
-
-**Результат**: 12 зависимостей найдено! ✅
-
-### Момент 8: Классификация параметров
-
-**Мышление**:
- Параметры разные по смыслу
- Нужно их классифицировать
-
-**Классификация**:
-1. **User/Owner references**: `s3UserUid`, `organizationUid`, `vdcUid`
-   - Указывают на "владельца" или "родительский" сервис
-
-2. **Configuration items**: `bucketName`, `recordName`
-   - Текстовые идентификаторы (не UUID)
-
-3. **Startup dependencies**: `startupConfiguration.vdcUid`
-   - Требуются для инициализации
-
-4. **Data integration**: `s3Uid` в PostgreSQL
-   - Интеграция между сервисами
-
---
-
-## День 4: Visualization Issues
-
-### Момент 9: Диаграмма слишком маленькая
-
-**Проблема**: На Mermaid в VS Code диаграмма маленькая, не видно деталей
-
-**Первое решение**: "Создам HTML с Mermaid.js!"
-
-**Но!** Новая проблема: файл на WSL, file:// не работает
-
-### Момент 10: file:// protocol в WSL
-
-**Ошибка**:
-```
-ERR_FILE_NOT_FOUND (-6)
-URL: file:///home/naeel/remote_dev/sless/...
-```
-
-**Мышление**:
- ❌ Дефект браузера?
- ❌ Дефект WSL?
- ✅ **file:// в WSL не открывает обычные файлы!**
-
-**Решение**: HTTP server
-```bash
-python3 -m http.server 8080
-# Теперь http://localhost:8080 работает!
-```
-
-### Момент 11: Zoom проблема
-
-**Попытка 1**: CSS `transform: scale(2)`
-```css
-.diagram-container {
-    transform: scale(2);
-}
-```
-
-**Результат**: ❌ Диаграмма увеличена, но скролла нет!!!
-
-**Почему**: `transform` не влияет на `overflow`, потому что это хак (визуальное преобразование)
-
-**Попытка 2**: CSS `zoom: 2`
-```css
-.diagram-container {
-    zoom: 2;
-}
-```
-
-**Результат**: ✅ Работает! Скролл работает!
-
-**Урок**: 
- `transform` = визуальное преобразование (не влияет на layout)
- `zoom` = изменение scale всего содержимого (влияет на layout и скролл)
-
-### Момент 12: JavaScript зума
-
-**Первая попытка**: Обновлять `transform` в JS
-```javascript
-container.style.transform = `scale(${currentZoom})`;
-```
-
-**Проблема**: Скролл не работает
-
-**Вторая попытка**: Обновлять `zoom` в JS
-```javascript
-container.style.zoom = currentZoom;
-```
-
-**Результат**: ✅ Работает идеально!
-
---
-
-## День 5: Documentation
-
-### Момент 13: Что документировать?
-
-**Мышление**:
- Пользователь просил "ОЧЕНЬ подробно описать ВСЁ"
- Включая ошибки и неверные решения
- Чтобы новый агент понял
-
-**План документации**:
-1. README (общий обзор)
-2. THINKING_PROCESS (как я думал)
-3. ERRORS_SOLUTIONS (все ошибки)
-4. API_FINDINGS (что открыл об API)
-5. DATA_STRUCTURE (структура данных)
-6. NEXT_STEPS (будущие улучшения)
-
---
-
-## Итоги мышления
-
-**Ключевые принципы, которые применил**:
-
-1. **Исследование перед действием**
-   - Изучил исходный код вместо гадания
-   - Результат: правильный endpoint с первого раза после анализа
-
-2. **Итеративное улучшение**
-   - Попробовал, не сработало, понял почему, исправил
-   - Пример: transform → zoom для скролла
-
-3. **Классификация и организация**
-   - Параметры сгруппировал по типам
-   - Инстансы сгруппировал по платформам
-   - Результат: понятная архитектура
-
-4. **Документирование процесса**
-   - Не только результат, но и путь туда
-   - Включая ошибки (как учиться на них)
-   - Результат: новый агент может продолжить работу
-
-5. **Проверка предположений**
-   - Не угадывал: "Может быть, это работает так?"
-   - Проверял: регулярно печатал данные, смотрел результат
-   - Результат: никаких неправильных исправлений
-
---
-
-**Сессия завершена**: 100% уверенность в результате ✅
@@ -1,552 +0,0 @@
-#!/bin/bash
-# compare_sqs.sh — Сравнительный тест двух SQS реализаций
-# Created: 2026-04-10
-#
-# Сравниваем:
-#   A) sqs-operator  — https://sqs.kube5s.ru/sqs/{tenant}  (1 тенант = 1 namespace в k8s)
-#   B) shared-sqs   — https://qu.kube5s.ru                 (Single-process, multitenancy через API)
-#
-# Метрики:
-#   - Время создания тенанта
-#   - Время CRUD очереди (create/send/receive/delete)
-#   - Время удаления тенанта
-#   - Ресурсы pods после N тенантов (kubectl top)
-#
-# Запуск:
-#   bash compare_sqs.sh [TENANTS]
-#   TENANTS=10 bash compare_sqs.sh
-#   TENANTS=20 bash compare_sqs.sh
-#   TENANTS=50 bash compare_sqs.sh
-#
-# Требования:
-#   - kubectl с доступом к кластеру
-#   - curl
-#   - python3
-#   - aws CLI (для shared-sqs CRUD)
-#
-# Для sqs-operator: тенант создаётся через kubectl apply QueueService CR
-# Для shared-sqs:   тенант создаётся через POST /admin/tenants
-
-set -uo pipefail
-
-# ════════════════════════════════════════════
-# КОНФИГ
-# ════════════════════════════════════════════
-
-# Количество тенантов — передаётся аргументом или переменной или по умолчанию 10
-TENANTS="${1:-${TENANTS:-10}}"
-
-# sqs-operator
-OP_HOST="https://sqs.kube5s.ru"
-OP_CR_NAMESPACE="sqs-operator-system"
-# Namespace тенантов в sqs-operator: sless-fn-{tenant}
-OP_TENANT_NS_PREFIX="sless-fn"
-# Шаблон QueueService CR (apiVersion из реального кода)
-OP_CR_TEMPLATE='apiVersion: sqs.kube5s.ru/v1alpha1
-kind: QueueService
-metadata:
-  name: CRNAME
-  namespace: sqs-operator-system
-spec:
-  tenantId: TENANTID
-  memoryMB: 64
-  storageMB: 512
-  persistence: false'
-
-# shared-sqs
-SS_HOST="https://qu.kube5s.ru"
-SS_ADMIN_TOKEN="${SS_ADMIN_TOKEN:-sqs-admin-7a7d8bd0c060a75c198d48680f34077a}"
-SS_REGION="us-east-1"
-SS_NAMESPACE="sless"        # namespace где живёт shared-sqs pod (для kubectl top)
-
-# Имя пода shared-sqs в k8s (для ресурсов)
-SS_DEPLOY_LABEL="app=shared-sqs"
-OP_MANAGER_LABEL="control-plane=controller-manager"
-OP_TENANT_LABEL_PREFIX="sless.dev/tenant"
-
-# Таймаут ожидания QueueService Ready (секунд)
-OP_READY_TIMEOUT=120
-
-# ════════════════════════════════════════════
-# УТИЛИТЫ
-# ════════════════════════════════════════════
-
-PASS=0; FAIL=0
-RESULTS_FILE="/tmp/sqs_compare_$(date +%s).log"
-
-ok()   { echo "  ✅ $1"; PASS=$((PASS+1)); }
-fail() { echo "  ❌ $1"; FAIL=$((FAIL+1)); }
-hdr()  { echo ""; echo "══════════════════════════════════════════"; echo "  $1"; echo "══════════════════════════════════════════"; }
-ts()   { date '+%H:%M:%S'; }
-elapsed_ms() {
-    # $1 = start seconds (с дробной частью от date +%s%3N)
-    local start="$1"
-    local end
-    end=$(date +%s%3N)
-    echo $(( end - start ))
-}
-
-# Запись результата в файл для итоговой таблицы
-record() {
-    # $1=impl $2=phase $3=n_tenants $4=value_ms $5=label
-    echo "$1,$2,$3,$4,$5" >> "$RESULTS_FILE"
-}
-
-# ─── sqs-operator API ───
-op_sqs() {
-    # $1=endpoint $2=ak $3=sk $4=query_params
-    curl -sk --max-time 15 \
-        --aws-sigv4 "aws:amz:us-east-1:sqs" \
-        --user "$2:$3" \
-        "${1}/?${4}&Version=2012-11-05"
-}
-
-# Ожидать QueueService Phase=Ready
-op_wait_ready() {
-    local crname="$1" max_sec="$2"
-    local start
-    start=$(date +%s)
-    while true; do
-        local phase
-        phase=$(kubectl get queueservice "$crname" -n "$OP_CR_NAMESPACE" \
-            -o jsonpath='{.status.phase}' 2>/dev/null || echo "")
-        [ "$phase" = "Ready" ] && return 0
-        local now
-        now=$(date +%s)
-        [ $(( now - start )) -ge "$max_sec" ] && return 1
-        sleep 2
-    done
-}
-
-# Проверить что QueueService CR API доступен (идемпотентно)
-op_check_api() {
-    local tenantid="$1"
-    local ep="${OP_HOST}/sqs/${tenantid}"
-    # Для credentials нужен secret в k8s
-    local ns="${OP_TENANT_NS_PREFIX}-${tenantid}"
-    local ak sk
-    ak=$(kubectl -n "$ns" get secret "sqs-creds-${tenantid}" \
-        -o jsonpath='{.data.accessKey}' 2>/dev/null | base64 -d 2>/dev/null || echo "")
-    sk=$(kubectl -n "$ns" get secret "sqs-creds-${tenantid}" \
-        -o jsonpath='{.data.secretKey}' 2>/dev/null | base64 -d 2>/dev/null || echo "")
-    echo "$ak:$sk:$ep"
-}
-
-# ─── shared-sqs Admin API ───
-ss_admin() {
-    local method="$1" path="$2" body="${3:-}"
-    if [[ -n "$body" ]]; then
-        curl -sf --max-time 15 \
-            -X "$method" \
-            -H "Authorization: Bearer $SS_ADMIN_TOKEN" \
-            -H "Content-Type: application/json" \
-            -d "$body" \
-            "${SS_HOST}${path}" 2>&1
-    else
-        curl -sf --max-time 15 \
-            -X "$method" \
-            -H "Authorization: Bearer $SS_ADMIN_TOKEN" \
-            "${SS_HOST}${path}" 2>&1
-    fi
-}
-
-ss_sqs() {
-    # $1=ak $2=sk $3=action_params
-    curl -sk --max-time 15 \
-        -u "$1:$2" \
-        "${SS_HOST}/?${3}&Version=2012-11-05" 2>&1
-}
-
-# ════════════════════════════════════════════
-# ПРОВЕРКА ДОСТУПНОСТИ
-# ════════════════════════════════════════════
-hdr "0. Проверка доступности (N=$TENANTS тенантов)"
-
-OP_HEALTH=$(curl -sk --max-time 5 -o /dev/null -w "%{http_code}" "${OP_HOST}/sqs/test001" 2>/dev/null || echo "0")
-SS_HEALTH=$(curl -sk --max-time 5 -o /dev/null -w "%{http_code}" "${SS_HOST}/health" 2>/dev/null || echo "0")
-
-echo "  sqs-operator  (${OP_HOST}): HTTP $OP_HEALTH"
-echo "  shared-sqs    (${SS_HOST}): HTTP $SS_HEALTH"
-
-# kubectl доступен?
-KUBECTL_OK=false
-if kubectl cluster-info &>/dev/null; then
-    KUBECTL_OK=true
-    echo "  kubectl: OK ($(kubectl config current-context))"
-else
-    echo "  kubectl: НЕДОСТУПЕН — метрики ресурсов будут пропущены"
-fi
-
-# aws cli доступен?
-AWS_CLI_OK=false
-if command -v aws &>/dev/null; then
-    AWS_CLI_OK=true
-    echo "  aws CLI: OK"
-else
-    echo "  aws CLI: НЕДОСТУПЕН — shared-sqs CRUD будет через curl"
-fi
-
-# ════════════════════════════════════════════
-# ФАЗА 1 — Создание N тенантов
-# ════════════════════════════════════════════
-hdr "1. Создание $TENANTS тенантов"
-
-# Массивы для хранения созданных тенантов
-declare -a OP_TENANTS=()       # tenantId
-declare -a OP_CR_NAMES=()      # имя CR
-declare -a SS_TENANT_IDS=()    # UUID тенанта
-declare -a SS_AK_LIST=()       # Access Keys
-declare -a SS_SK_LIST=()       # Secret Keys
-
-echo ""
-echo "  ── A) sqs-operator ──"
-echo "     (каждый тенант = QueueService CR → новый namespace + deployment + secret)"
-echo ""
-
-OP_TOTAL_CREATE_MS=0
-OP_CREATE_TIMES=()
-
-for i in $(seq 1 "$TENANTS"); do
-    tid="cmp-op-$(printf '%03d' $i)-$$"
-    crname="cmp-cr-$(printf '%03d' $i)-$$"
-
-    # Применяем CR
-    CR_YAML=$(echo "$OP_CR_TEMPLATE" | sed "s/CRNAME/$crname/g" | sed "s/TENANTID/$tid/g")
-    t_start=$(date +%s%3N)
-    echo "$CR_YAML" | kubectl apply -f - &>/dev/null
-    apply_ok=$?
-
-    if [[ $apply_ok -ne 0 ]]; then
-        echo "  ❌ Тенант #$i ($tid): kubectl apply failed"
-        continue
-    fi
-
-    # Ждём Ready
-    if op_wait_ready "$crname" "$OP_READY_TIMEOUT"; then
-        t_ms=$(elapsed_ms "$t_start")
-        OP_CREATE_TIMES+=("$t_ms")
-        OP_TOTAL_CREATE_MS=$(( OP_TOTAL_CREATE_MS + t_ms ))
-        printf "  ✅ #%-3d %-40s %dms\n" "$i" "$tid" "$t_ms"
-        record "sqs-operator" "tenant_create" "$i" "$t_ms" "$tid"
-    else
-        echo "  ⚠️  #$i ($tid): timeout — не стал Ready за ${OP_READY_TIMEOUT}s"
-        record "sqs-operator" "tenant_create_timeout" "$i" "$OP_READY_TIMEOUT\000" "$tid"
-    fi
-
-    OP_TENANTS+=("$tid")
-    OP_CR_NAMES+=("$crname")
-done
-
-OP_CREATED=${#OP_TENANTS[@]}
-if [[ $OP_CREATED -gt 0 ]]; then
-    OP_AVG_CREATE=$(( OP_TOTAL_CREATE_MS / OP_CREATED ))
-    # Медиана
-    OP_SORTED_TIMES=($(printf '%s\n' "${OP_CREATE_TIMES[@]}" | sort -n))
-    OP_MEDIAN_CREATE=${OP_SORTED_TIMES[$(( OP_CREATED / 2 ))]}
-    printf "\n  Итого sqs-operator: создано %d/%d  avg=%dms  median=%dms\n" \
-        "$OP_CREATED" "$TENANTS" "$OP_AVG_CREATE" "$OP_MEDIAN_CREATE"
-fi
-
-echo ""
-echo "  ── B) shared-sqs ──"
-echo "     (тенант = POST /admin/tenants, всё в памяти одного процесса)"
-echo ""
-
-SS_TOTAL_CREATE_MS=0
-SS_CREATE_TIMES=()
-
-for i in $(seq 1 "$TENANTS"); do
-    tname="cmp-ss-$(printf '%03d' $i)-$$"
-    t_start=$(date +%s%3N)
-
-    RESP=$(ss_admin POST /admin/tenants "{\"name\":\"${tname}\",\"max_queues\":50}" 2>&1)
-    t_ms=$(elapsed_ms "$t_start")
-
-    if echo "$RESP" | grep -q "access_key"; then
-        ak=$(echo "$RESP" | python3 -c "import sys,json; print(json.load(sys.stdin)['access_key'])" 2>/dev/null || echo "")
-        sk=$(echo "$RESP" | python3 -c "import sys,json; print(json.load(sys.stdin)['secret_key'])" 2>/dev/null || echo "")
-        tid=$(echo "$RESP" | python3 -c "import sys,json; print(json.load(sys.stdin)['id'])" 2>/dev/null || echo "")
-
-        SS_CREATE_TIMES+=("$t_ms")
-        SS_TOTAL_CREATE_MS=$(( SS_TOTAL_CREATE_MS + t_ms ))
-        printf "  ✅ #%-3d %-40s %dms  (id=%s)\n" "$i" "$tname" "$t_ms" "${tid:0:12}..."
-        record "shared-sqs" "tenant_create" "$i" "$t_ms" "$tname"
-
-        SS_TENANT_IDS+=("$tid")
-        SS_AK_LIST+=("$ak")
-        SS_SK_LIST+=("$sk")
-    else
-        echo "  ❌ #$i ($tname): ошибка: ${RESP:0:100}"
-        record "shared-sqs" "tenant_create_error" "$i" "0" "$tname"
-    fi
-done
-
-SS_CREATED=${#SS_TENANT_IDS[@]}
-if [[ $SS_CREATED -gt 0 ]]; then
-    SS_AVG_CREATE=$(( SS_TOTAL_CREATE_MS / SS_CREATED ))
-    SS_SORTED_TIMES=($(printf '%s\n' "${SS_CREATE_TIMES[@]}" | sort -n))
-    SS_MEDIAN_CREATE=${SS_SORTED_TIMES[$(( SS_CREATED / 2 ))]}
-    printf "\n  Итого shared-sqs: создано %d/%d  avg=%dms  median=%dms\n" \
-        "$SS_CREATED" "$TENANTS" "$SS_AVG_CREATE" "$SS_MEDIAN_CREATE"
-fi
-
-# ════════════════════════════════════════════
-# ФАЗА 2 — CRUD очереди (первые 3 тенанта)
-# ════════════════════════════════════════════
-hdr "2. CRUD очереди (send+receive+delete, первые 3 тенанта каждой реализации)"
-
-CRUD_LIMIT=3
-
-echo ""
-echo "  ── A) sqs-operator CRUD ──"
-echo ""
-
-OP_CRUD_TIMES=()
-for idx in $(seq 0 $(( CRUD_LIMIT - 1 ))); do
-    [[ $idx -ge ${#OP_TENANTS[@]} ]] && break
-    tid="${OP_TENANTS[$idx]}"
-    crname="${OP_CR_NAMES[$idx]}"
-    creds=$(op_check_api "$tid")
-    ak=$(echo "$creds" | cut -d: -f1)
-    sk=$(echo "$creds" | cut -d: -f2)
-    ep=$(echo "$creds" | cut -d: -f3-)
-
-    if [[ -z "$ak" || -z "$sk" ]]; then
-        echo "  ⚠️  #$idx skipped — нет credentials (тенант не Ready?)"
-        continue
-    fi
-
-    qname="crud-q-$$-$idx"
-    t_start=$(date +%s%3N)
-
-    # CreateQueue
-    R=$(curl -sk --max-time 15 --aws-sigv4 "aws:amz:us-east-1:sqs" --user "$ak:$sk" \
-        "${ep}/?Action=CreateQueue&QueueName=${qname}&Version=2012-11-05")
-    QURL=$(echo "$R" | grep -oP "(?<=<QueueUrl>)[^<]+" || echo "")
-
-    if [[ -z "$QURL" ]]; then
-        echo "  ❌ #$idx CreateQueue failed: ${R:0:80}"
-        continue
-    fi
-
-    # SendMessage
-    curl -sk --max-time 15 --aws-sigv4 "aws:amz:us-east-1:sqs" --user "$ak:$sk" \
-        "${ep}/?Action=SendMessage&QueueUrl=${QURL}&MessageBody=compare-test-${idx}&Version=2012-11-05" >/dev/null
-
-    # ReceiveMessage
-    R=$(curl -sk --max-time 15 --aws-sigv4 "aws:amz:us-east-1:sqs" --user "$ak:$sk" \
-        "${ep}/?Action=ReceiveMessage&QueueUrl=${QURL}&MaxNumberOfMessages=1&Version=2012-11-05")
-    RECEIPT=$(echo "$R" | grep -oP "(?<=<ReceiptHandle>)[^<]+" | head -1 || echo "")
-
-    # DeleteMessage
-    if [[ -n "$RECEIPT" ]]; then
-        RECEIPT_ENC=$(echo "$RECEIPT" | python3 -c "import sys,urllib.parse; print(urllib.parse.quote(sys.stdin.read().strip()))")
-        curl -sk --max-time 15 --aws-sigv4 "aws:amz:us-east-1:sqs" --user "$ak:$sk" \
-            "${ep}/?Action=DeleteMessage&QueueUrl=${QURL}&ReceiptHandle=${RECEIPT_ENC}&Version=2012-11-05" >/dev/null
-    fi
-
-    # DeleteQueue
-    curl -sk --max-time 15 --aws-sigv4 "aws:amz:us-east-1:sqs" --user "$ak:$sk" \
-        "${ep}/?Action=DeleteQueue&QueueUrl=${QURL}&Version=2012-11-05" >/dev/null
-
-    t_ms=$(elapsed_ms "$t_start")
-    OP_CRUD_TIMES+=("$t_ms")
-    printf "  ✅ Tenant #%d %-36s CRUD %dms\n" "$idx" "$tid" "$t_ms"
-    record "sqs-operator" "crud" "$idx" "$t_ms" "$tid"
-done
-
-echo ""
-echo "  ── B) shared-sqs CRUD ──"
-echo ""
-
-SS_CRUD_TIMES=()
-for idx in $(seq 0 $(( CRUD_LIMIT - 1 ))); do
-    [[ $idx -ge ${#SS_TENANT_IDS[@]} ]] && break
-    tid="${SS_TENANT_IDS[$idx]}"
-    ak="${SS_AK_LIST[$idx]}"
-    sk="${SS_SK_LIST[$idx]}"
-    qname="crud-q-$$-$idx"
-
-    t_start=$(date +%s%3N)
-
-    # CreateQueue — shared-sqs требует AWS SigV4, не Basic Auth
-    R=$(curl -sk --max-time 15 \
-        --aws-sigv4 "aws:amz:us-east-1:sqs" --user "$ak:$sk" \
-        "${SS_HOST}/?Action=CreateQueue&QueueName=${qname}&Version=2012-11-05")
-    QURL=$(echo "$R" | grep -oP "(?<=<QueueUrl>)[^<]+" || echo "")
-
-    if [[ -z "$QURL" ]]; then
-        echo "  ❌ #$idx CreateQueue failed: ${R:0:80}"
-        continue
-    fi
-
-    # SendMessage
-    curl -sk --max-time 15 \
-        --aws-sigv4 "aws:amz:us-east-1:sqs" --user "$ak:$sk" \
-        "${SS_HOST}/?Action=SendMessage&QueueUrl=${QURL}&MessageBody=compare-test-${idx}&Version=2012-11-05" >/dev/null
-
-    # ReceiveMessage
-    R=$(curl -sk --max-time 15 \
-        --aws-sigv4 "aws:amz:us-east-1:sqs" --user "$ak:$sk" \
-        "${SS_HOST}/?Action=ReceiveMessage&QueueUrl=${QURL}&MaxNumberOfMessages=1&Version=2012-11-05")
-    RECEIPT=$(echo "$R" | grep -oP "(?<=<ReceiptHandle>)[^<]+" | head -1 || echo "")
-
-    # DeleteMessage
-    if [[ -n "$RECEIPT" ]]; then
-        RECEIPT_ENC=$(echo "$RECEIPT" | python3 -c "import sys,urllib.parse; print(urllib.parse.quote(sys.stdin.read().strip()))")
-        curl -sk --max-time 15 \
-            --aws-sigv4 "aws:amz:us-east-1:sqs" --user "$ak:$sk" \
-            "${SS_HOST}/?Action=DeleteMessage&QueueUrl=${QURL}&ReceiptHandle=${RECEIPT_ENC}&Version=2012-11-05" >/dev/null
-    fi
-
-    # DeleteQueue
-    curl -sk --max-time 15 \
-        --aws-sigv4 "aws:amz:us-east-1:sqs" --user "$ak:$sk" \
-        "${SS_HOST}/?Action=DeleteQueue&QueueUrl=${QURL}&Version=2012-11-05" >/dev/null
-
-    t_ms=$(elapsed_ms "$t_start")
-    SS_CRUD_TIMES+=("$t_ms")
-    printf "  ✅ Tenant #%d %-36s CRUD %dms\n" "$idx" "${tid:0:20}..." "$t_ms"
-    record "shared-sqs" "crud" "$idx" "$t_ms" "${tid:0:12}"
-done
-
-# ════════════════════════════════════════════
-# ФАЗА 3 — Ресурсы (kubectl top)
-# ════════════════════════════════════════════
-hdr "3. Ресурсы при $TENANTS тенантах (kubectl top)"
-
-if [[ "$KUBECTL_OK" == "true" ]]; then
-    echo ""
-    echo "  ── A) sqs-operator pods ──"
-    # Controller manager
-    echo "  -- Controller manager:"
-    kubectl top pods -n "$OP_CR_NAMESPACE" -l "$OP_MANAGER_LABEL" 2>/dev/null || echo "    (kubectl top недоступен — metrics-server?)"
-    # Tenant pods — все ns с prefix sless-fn-cmp-
-    echo "  -- Tenant pods (cmp-* namespaces):"
-    for tid in "${OP_TENANTS[@]}"; do
-        ns="${OP_TENANT_NS_PREFIX}-${tid}"
-        kubectl top pods -n "$ns" 2>/dev/null | grep -v "^NAME" | \
-            awk -v ns="$ns" '{printf "    %-50s  CPU=%-8s MEM=%s\n", ns"/"$1, $2, $3}' 2>/dev/null || true
-    done
-    # Суммарно: кол-во pods
-    OP_NS_COUNT=$(kubectl get ns | grep -c "sless-fn-cmp-" 2>/dev/null || echo "?")
-    echo "  -- Итого namespace под тенанты: $OP_NS_COUNT"
-
-    echo ""
-    echo "  ── B) shared-sqs pod ──"
-    kubectl top pods -n "$SS_NAMESPACE" -l "$SS_DEPLOY_LABEL" 2>/dev/null || \
-    kubectl top pods -n "$SS_NAMESPACE" 2>/dev/null | grep -i "shared-sqs\|sqs" | \
-        awk '{printf "    %-50s  CPU=%-8s MEM=%s\n", $1, $2, $3}' || \
-    echo "    (pod не найден в namespace $SS_NAMESPACE)"
-    echo "  -- Тенанты в памяти: $SS_CREATED (0 дополнительных pods)"
-else
-    echo "  kubectl недоступен — пропускаем"
-fi
-
-# ════════════════════════════════════════════
-# ФАЗА 4 — Cleanup
-# ════════════════════════════════════════════
-hdr "4. Cleanup"
-
-echo ""
-echo "  ── A) sqs-operator ──"
-OP_DEL_TIMES=()
-for i in "${!OP_CR_NAMES[@]}"; do
-    crname="${OP_CR_NAMES[$i]}"
-    t_start=$(date +%s%3N)
-    kubectl delete queueservice "$crname" -n "$OP_CR_NAMESPACE" --wait=false &>/dev/null
-    t_ms=$(elapsed_ms "$t_start")
-    OP_DEL_TIMES+=("$t_ms")
-    record "sqs-operator" "tenant_delete" "$i" "$t_ms" "$crname"
-done
-echo "  Удалено ${#OP_CR_NAMES[@]} CR (без ожидания термин.)"
-
-echo ""
-echo "  ── B) shared-sqs ──"
-SS_DEL_TIMES=()
-for i in "${!SS_TENANT_IDS[@]}"; do
-    tid="${SS_TENANT_IDS[$i]}"
-    t_start=$(date +%s%3N)
-    ss_admin DELETE "/admin/tenants/$tid" >/dev/null 2>&1
-    t_ms=$(elapsed_ms "$t_start")
-    SS_DEL_TIMES+=("$t_ms")
-    record "shared-sqs" "tenant_delete" "$i" "$t_ms" "${tid:0:12}"
-done
-
-if [[ ${#SS_DEL_TIMES[@]} -gt 0 ]]; then
-    SS_AVG_DEL=$(python3 -c "t=[${SS_DEL_TIMES[*]}]; print(int(sum(t)/len(t)))" 2>/dev/null || echo "?")
-    echo "  Удалено ${#SS_DEL_TIMES[@]} тенантов  avg=${SS_AVG_DEL}ms"
-fi
-
-# ════════════════════════════════════════════
-# ИТОГОВАЯ ТАБЛИЦА
-# ════════════════════════════════════════════
-hdr "ИТОГ — Сравнительная таблица (N=$TENANTS)"
-
-python3 - << PYEOF
-import csv, sys
-
-data = {}
-
-# Парсим results file
-try:
-    with open("$RESULTS_FILE") as f:
-        for row in csv.reader(f):
-            if len(row) < 5:
-                continue
-            impl, phase, n, val_str, label = row
-            try:
-                val = int(val_str)
-            except:
-                continue
-            key = (impl, phase)
-            data.setdefault(key, []).append(val)
-except FileNotFoundError:
-    print("Нет результатов")
-    sys.exit(0)
-
-def stats(vals):
-    if not vals:
-        return "нет данных"
-    vals_s = sorted(vals)
-    n = len(vals_s)
-    avg = int(sum(vals_s) / n)
-    med = vals_s[n // 2]
-    mn  = vals_s[0]
-    mx  = vals_s[-1]
-    return f"avg={avg}ms  med={med}ms  min={mn}ms  max={mx}ms  n={n}"
-
-print("")
-print(f"{'Метрика':<30} {'sqs-operator':<50} {'shared-sqs':<50}")
-print("-" * 130)
-
-phases = [
-    ("tenant_create",  "Создание тенанта"),
-    ("crud",           "CRUD очереди (create+send+recv+del)"),
-    ("tenant_delete",  "Удаление тенанта"),
-]
-
-for phase_key, phase_label in phases:
-    op_vals = data.get(("sqs-operator", phase_key), [])
-    ss_vals = data.get(("shared-sqs",   phase_key), [])
-    print(f"  {phase_label:<28} {stats(op_vals):<50} {stats(ss_vals):<50}")
-
-print("")
-
-# Вывод победителя по скорости создания
-op_create = data.get(("sqs-operator", "tenant_create"), [])
-ss_create = data.get(("shared-sqs",   "tenant_create"), [])
-if op_create and ss_create:
-    op_avg = sum(op_create) / len(op_create)
-    ss_avg = sum(ss_create) / len(ss_create)
-    ratio  = op_avg / ss_avg if ss_avg > 0 else float('inf')
-    faster = "shared-sqs" if ss_avg < op_avg else "sqs-operator"
-    print(f"  Создание тенанта: {faster} быстрее в {ratio:.1f}x")
-    print(f"    sqs-operator: {op_avg:.0f}ms  |  shared-sqs: {ss_avg:.0f}ms")
-
-print("")
-print(f"  Файл подробных данных: $RESULTS_FILE")
-PYEOF
-
-echo ""
-echo "  Готово! $(date '+%Y-%m-%d %H:%M:%S')"
@@ -1,123 +0,0 @@
---
-apiVersion: apiextensions.k8s.io/v1
-kind: CustomResourceDefinition
-metadata:
-  annotations:
-    controller-gen.kubebuilder.io/version: v0.14.0
-  name: iotdevices.iot.kube5s.ru
-spec:
-  group: iot.kube5s.ru
-  names:
-    kind: IoTDevice
-    listKind: IoTDeviceList
-    plural: iotdevices
-    singular: iotdevice
-  scope: Namespaced
-  versions:
-  - additionalPrinterColumns:
-    - jsonPath: .spec.deviceId
-      name: DeviceID
-      type: string
-    - jsonPath: .status.phase
-      name: Phase
-      type: string
-    - jsonPath: .spec.enabled
-      name: Enabled
-      type: boolean
-    - jsonPath: .status.mqttUsername
-      name: MQTTUser
-      type: string
-    - jsonPath: .metadata.creationTimestamp
-      name: Age
-      type: date
-    name: v1alpha1
-    schema:
-      openAPIV3Schema:
-        description: |-
-          IoTDevice — ресурс для регистрации IoT-устройства в платформе.
-          Контроллер автоматически создаёт k8s Secret с MQTT-credentials.
-        properties:
-          apiVersion:
-            description: |-
-              APIVersion defines the versioned schema of this representation of an object.
-              Servers should convert recognized schemas to the latest internal value, and
-              may reject unrecognized values.
-              More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
-            type: string
-          kind:
-            description: |-
-              Kind is a string value representing the REST resource this object represents.
-              Servers may infer this from the endpoint the client submits requests to.
-              Cannot be updated.
-              In CamelCase.
-              More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
-            type: string
-          metadata:
-            type: object
-          spec:
-            description: IoTDeviceSpec — желаемое состояние IoT-устройства.
-            properties:
-              deviceId:
-                description: |-
-                  DeviceID — уникальный идентификатор устройства внутри namespace.
-                  Используется как часть MQTT username и имени Secret.
-                  Разрешены только строчные буквы, цифры и дефис — для совместимости с k8s именами.
-                maxLength: 48
-                pattern: ^[a-z0-9][a-z0-9-]*[a-z0-9]$
-                type: string
-              enabled:
-                default: true
-                description: |-
-                  Enabled — активно ли устройство (может подключаться к MQTT).
-                  Если false — контроллер устанавливает phase=Disabled, EMQX auth отклоняет подключение.
-                  Secret с credentials НЕ удаляется — при re-enable пароль остаётся прежним.
-                type: boolean
-              metadata:
-                additionalProperties:
-                  type: string
-                description: |-
-                  Metadata — произвольные метаданные устройства (модель, локация и т.д.).
-                  Хранятся только в CRD, не влияют на логику контроллера.
-                type: object
-            required:
-            - deviceId
-            - enabled
-            type: object
-          status:
-            description: IoTDeviceStatus — наблюдаемое состояние IoT-устройства (заполняет
-              контроллер).
-            properties:
-              lastConnected:
-                description: |-
-                  LastConnected — время последнего MQTT-подключения устройства.
-                  Заполняется MQTT auth-сервисом при каждом успешном CONNECT.
-                format: date-time
-                type: string
-              message:
-                description: Message — человекочитаемое сообщение о текущем статусе
-                  или ошибке.
-                type: string
-              mqttUsername:
-                description: |-
-                  MQTTUsername — имя пользователя для подключения к MQTT-брокеру.
-                  Формат: {namespace}_{deviceId} — глобально уникален в рамках EMQX.
-                type: string
-              phase:
-                description: 'Phase — текущее состояние: Active, Disabled, Pending,
-                  Error.'
-                type: string
-              secretName:
-                description: SecretName — имя k8s Secret в том же namespace, содержащего
-                  mqtt-username и mqtt-password.
-                type: string
-              topicPrefix:
-                description: |-
-                  TopicPrefix — MQTT topic prefix, на который разрешена публикация.
-                  Формат: {namespace}/ — устройство не может публиковать в чужие namespace.
-                type: string
-            type: object
-        type: object
-    served: true
-    storage: true
-    subresources:
-      status: {}
@@ -85,11 +85,11 @@ spec:
                description: S3Key — ключ объекта в S3 (путь до zip архива)
                type: string
              timeoutSec:
+                default: 30
                description: |-
-                  TimeoutSec — таймаут HTTP-прокси в секундах.
-                  0 (по умолчанию) = без ограничения времени выполнения.
-                  Задай > 0 чтобы принудительно обрывать медленные вызовы.
-                  Диапазон: 1–900. 0 = нет таймаута.
+                  TimeoutSec — таймаут HTTP-прокси в секундах (default: 30).
+                  Ограничивает время ожидания ответа от пода в invoke.go.
+                  Для длительных вызовов (batch, pgstorm) увеличить до нужного значения.
                format: int32
                type: integer
            required:
@@ -26,10 +26,7 @@ rules:
  - secrets
  verbs:
  - create
-  - delete
  - get
-  - list
-  - watch
 - apiGroups:
  - ""
  resources:
@@ -78,32 +75,6 @@ rules:
  - patch
  - update
  - watch
- apiGroups:
-  - iot.kube5s.ru
-  resources:
-  - iotdevices
-  verbs:
-  - create
-  - delete
-  - get
-  - list
-  - patch
-  - update
-  - watch
- apiGroups:
-  - iot.kube5s.ru
-  resources:
-  - iotdevices/finalizers
-  verbs:
-  - update
- apiGroups:
-  - iot.kube5s.ru
-  resources:
-  - iotdevices/status
-  verbs:
-  - get
-  - patch
-  - update
 - apiGroups:
  - networking.k8s.io
  resources:
@@ -168,32 +139,6 @@ rules:
  - get
  - patch
  - update
- apiGroups:
-  - sless.kube5s.ru
-  resources:
-  - services
-  verbs:
-  - create
-  - delete
-  - get
-  - list
-  - patch
-  - update
-  - watch
- apiGroups:
-  - sless.kube5s.ru
-  resources:
-  - services/finalizers
-  verbs:
-  - update
- apiGroups:
-  - sless.kube5s.ru
-  resources:
-  - services/status
-  verbs:
-  - get
-  - patch
-  - update
 - apiGroups:
  - sless.kube5s.ru
  resources:
@@ -1,70 +0,0 @@
-# Изменено: 2026-04-04 (tls: добавлен TLS + cert-manager, wss://, https://)
-# WORKAROUND: MQTT over WebSocket через порт 443.
-# Причина: порт 1883 заблокирован NSX-T Edge firewall на уровне облака.
-# Решение: EMQX WebSocket listener (8083) проксируется через nginx-ingress с TLS termination.
-#
-# IoT устройство подключается: wss://iot.kube5s.ru/mqtt
-# IoT Консоль (UI): https://iot.kube5s.ru/console
-#
-# DNS A-запись: iot.kube5s.ru → 185.247.187.147 (создана через Nubes API, zoneUid=498096ee)
-# TLS: cert-manager + letsencrypt-prod, secret=iot-kube5s-ru-tls
-#
-# Когда DevOps откроет порт 1883 — этот файл можно удалить.
---
-apiVersion: v1
-kind: Service
-metadata:
-  name: emqx-ws
-  namespace: sless
-  # Отдельный Service чтобы не путать — WebSocket порт для Ingress
-spec:
-  selector:
-    app: emqx
-  ports:
-    - name: mqtt-ws
-      port: 8083
-      targetPort: 8083
-      protocol: TCP
---
-apiVersion: networking.k8s.io/v1
-kind: Ingress
-metadata:
-  name: emqx-mqtt-websocket
-  namespace: sless
-  annotations:
-    kubernetes.io/ingress.class: nginx
-    cert-manager.io/cluster-issuer: letsencrypt-prod
-    # ssl-redirect=true: принудительно HTTPS для всего трафика на iot.kube5s.ru
-    nginx.ingress.kubernetes.io/ssl-redirect: "true"
-    # WebSocket: nginx-ingress автоматически добавляет Upgrade/Connection при proxy-http-version=1.1
-    nginx.ingress.kubernetes.io/proxy-http-version: "1.1"
-    nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
-    nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
-spec:
-  ingressClassName: nginx
-  tls:
-    - hosts:
-        - iot.kube5s.ru
-      secretName: iot-kube5s-ru-tls
-  rules:
-    - host: iot.kube5s.ru
-      http:
-        paths:
-          # MQTT over WebSocket — для подключения IoT устройств и браузерного эмулятора
-          - path: /mqtt
-            pathType: Exact
-            backend:
-              service:
-                name: emqx-ws
-                port:
-                  number: 8083
-          # IoT Консоль (UI) — HTML SPA встроенный в бинарник sless-operator
-          # URL: https://iot.kube5s.ru/console
-          # TLS termination на Ingress → wss:// MQTT и https:// API работают без mixed content
-          - path: /console
-            pathType: Exact
-            backend:
-              service:
-                name: sless-operator
-                port:
-                  number: 9090
@@ -1,197 +0,0 @@
-# Создано: 2026-04-04
-# EMQX MQTT-брокер для IoT-сервиса (namespace: sless).
-#
-# Архитектура:
-#   IoT Device → MQTT CONNECT → EMQX (HTTP auth → sless-operator:9090/internal/mqtt/auth)
-#   EMQX → MQTT PUBLISH → sless-iot-bridge (paho subscriber) → RabbitMQ queue iot.{ns}.telemetry
-#   RabbitMQ → event-dispatcher → serverless function
-#
-# EMQX 5.x конфиг через emqx.conf (HOCON формат), монтируется как ConfigMap volume.
-# НЕ используем env vars для конфигурации EMQX 5.x — они не поддерживаются аналогично 4.x.
-#
-# Порты:
-#   1883 — MQTT (plaintext)
-#   8883 — MQTTS (TLS, для prod надо настроить certSecret)
-#   8083 — MQTT over WebSocket
-#   18083 — EMQX Dashboard (admin/public по умолчанию — менять в prod!)
-#
-# Применение: kubectl apply -f deployments/k8s/emqx.yaml
-
---
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: emqx-config
-  namespace: sless
-data:
-  # emqx.conf — HOCON конфиг для EMQX 5.5.x
-  # Раздел authentication: HTTP Backend для проверки MQTT credentials IoT-устройств.
-  # Наш сервис (sless-operator) ищет Secret iot-{deviceId} и сравнивает пароль.
-  emqx.conf: |
-    ## EMQX 5.x configuration (HOCON format)
-    ## Изменено: 2026-04-04
-
-    ## Обязательные поля node — без них EMQX 5.x падает при старте
-    ## node.cookie — секрет кластерного Erlang-соединения, для single-node любая строка
-    ## node.data_dir — директория данных (mnesia, конфиги), должна существовать в контейнере
-    node {
-      name = "emqx@127.0.0.1"
-      cookie = "sless-emqx-cookie-mvp"
-      data_dir = "/opt/emqx/data"
-    }
-
-    ## HTTP Auth Backend для IoT-устройств
-    ## EMQX посылает POST с {username, password, clientid} → наш сервис отвечает {"result":"allow"|"deny"}
-    authentication = [
-      {
-        mechanism = password_based
-        backend = http
-        enable = true
-        method = post
-        url = "http://sless-operator.sless.svc:9090/internal/mqtt/auth"
-        body {
-          username = "${username}"
-          password = "${password}"
-          clientid = "${clientid}"
-        }
-        headers {
-          "content-type" = "application/json"
-        }
-        connect_timeout = 5s
-        request_timeout = 5s
-        ## allow_timeout_error = false — если наш сервис не отвечает, deny (безопаснее)
-        pool_size = 8
-      }
-    ]
-
-    ## Authorization (ACL) — HTTP backend для изоляции топиков по устройству.
-    ## no_match = deny: если HTTP backend недоступен или не ответил — запрещаем.
-    ## Endpoint /internal/mqtt/acl возвращает allow только для топиков {ns}/{deviceId}/#
-    authorization {
-      no_match = deny
-      deny_action = disconnect
-      cache {
-        enable = true
-        max_size = 32
-        ttl = 1m
-      }
-      sources = [
-        {
-          type = http
-          enable = true
-          method = post
-          url = "http://sless-operator.sless.svc:9090/internal/mqtt/acl"
-          body {
-            username = "${username}"
-            clientid = "${clientid}"
-            action = "${action}"
-            topic = "${topic}"
-          }
-          headers {
-            "content-type" = "application/json"
-          }
-          connect_timeout = 5s
-          request_timeout = 5s
-          pool_size = 8
-        }
-      ]
-    }
-
-    ## MQTT настройки
-    mqtt {
-      max_packet_size = 1MB
-      max_topic_levels = 10
-      retain_available = false
-    }
-
-    ## Listeners — только plaintext MQTT для MVP
-    ## TLS (8883) отключён — настроить при необходимости
-    listeners.tcp.default {
-      bind = "0.0.0.0:1883"
-      max_connections = 1024
-    }
-
-    listeners.ws.default {
-      bind = "0.0.0.0:8083"
-      max_connections = 512
-    }
-
-    ## Dashboard
-    dashboard {
-      listeners.http {
-        bind = 18083
-      }
-    }
---
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: emqx
-  namespace: sless
-  labels:
-    app: emqx
-spec:
-  replicas: 1
-  selector:
-    matchLabels:
-      app: emqx
-  template:
-    metadata:
-      labels:
-        app: emqx
-    spec:
-      containers:
-        - name: emqx
-          image: emqx/emqx:5.5.1
-          ports:
-            - name: mqtt
-              containerPort: 1883
-            - name: ws
-              containerPort: 8083
-            - name: dashboard
-              containerPort: 18083
-          volumeMounts:
-            - name: emqx-conf
-              mountPath: /opt/emqx/etc/emqx.conf
-              subPath: emqx.conf
-          resources:
-            requests:
-              memory: "256Mi"
-              cpu: "100m"
-            limits:
-              memory: "512Mi"
-              cpu: "500m"
-          readinessProbe:
-            tcpSocket:
-              port: 1883
-            initialDelaySeconds: 20
-            periodSeconds: 10
-            timeoutSeconds: 5
-          livenessProbe:
-            tcpSocket:
-              port: 1883
-            initialDelaySeconds: 40
-            periodSeconds: 20
-      volumes:
-        - name: emqx-conf
-          configMap:
-            name: emqx-config
---
-apiVersion: v1
-kind: Service
-metadata:
-  name: emqx
-  namespace: sless
-spec:
-  selector:
-    app: emqx
-  ports:
-    - name: mqtt
-      port: 1883
-      targetPort: 1883
-    - name: ws
-      port: 8083
-      targetPort: 8083
-    - name: dashboard
-      port: 18083
-      targetPort: 18083
@@ -1,48 +0,0 @@
-# Создано: 2026-04-06
-# Deployment iot-kafka-consumer — читает IoT телеметрию из Kafka → пишет в IoT Postgres.
-#
-# Consumer group "iot-pg-consumer" — можно масштабировать горизонтально без дублирования.
-# Offset коммитится ТОЛЬКО после успешной записи в Postgres (at-least-once гарантия).
-#
-# Применение: kubectl apply -f deployments/k8s/iot-kafka-consumer.yaml
-
---
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: iot-kafka-consumer
-  namespace: sless
-  labels:
-    app: iot-kafka-consumer
-spec:
-  replicas: 1
-  selector:
-    matchLabels:
-      app: iot-kafka-consumer
-  template:
-    metadata:
-      labels:
-        app: iot-kafka-consumer
-    spec:
-      containers:
-        - name: kafka-consumer
-          # Тот же образ что и оператор — все IoT бинари в одном образе.
-          image: pearlharbor.registryk8s.services.ngcloud.ru/naeel/sless-operator:v0.1.69
-          imagePullPolicy: Always
-          command: ["/iot-kafka-consumer"]
-          env:
-            - name: KAFKA_BROKERS
-              value: "kafka.sless.svc.cluster.local:9092"
-          envFrom:
-            # IOT_PG_DSN — master DSN для IoT Postgres (per-tenant DB)
-            - secretRef:
-                name: iot-postgres-secret
-          resources:
-            requests:
-              memory: "32Mi"
-              cpu: "25m"
-            limits:
-              memory: "64Mi"
-              cpu: "100m"
-      imagePullSecrets:
-        - name: sless-registry-auth
@@ -1,71 +0,0 @@
-# Создано: 2026-04-04
-# Изменено: 2026-04-06 (MQTT→Kafka: убран RABBITMQ_URL, добавлен KAFKA_BROKERS, v0.1.67)
-# Deployment iot-mqtt-bridge — MQTT→Kafka мост для IoT.
-#
-# Получает MQTT сообщения от EMQX (подписка на "+/telemetry/+")
-# и публикует в Kafka топик "iot.telemetry" (ключ = namespace).
-#
-# Credentials для MQTT подключения берутся из Secret iot-bridge-credentials.
-# Этот Secret нужно создать вручную ДО деплоя:
-#
-#   # 1. Создать IoTDevice для bridge через API:
-#   curl -X POST .../v1/namespaces/sless-bridge/iot/devices \
-#     -d '{"name":"bridge","device_id":"bridge","enabled":true}'
-#
-#   # 2. Получить credentials:
-#   MQTT_USERNAME=$(kubectl get secret iot-bridge -n sless-bridge -o jsonpath='{.data.mqtt-username}' | base64 -d)
-#   MQTT_PASSWORD=$(kubectl get secret iot-bridge -n sless-bridge -o jsonpath='{.data.mqtt-password}' | base64 -d)
-#
-#   # 3. Создать Secret для bridge Deployment (один раз):
-#   kubectl create secret generic iot-bridge-credentials -n sless \
-#     --from-literal=MQTT_USERNAME="$MQTT_USERNAME" \
-#     --from-literal=MQTT_PASSWORD="$MQTT_PASSWORD"
-#
-# Применение: kubectl apply -f deployments/k8s/iot-mqtt-bridge.yaml
-
---
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: iot-mqtt-bridge
-  namespace: sless
-  labels:
-    app: iot-mqtt-bridge
-spec:
-  replicas: 1
-  selector:
-    matchLabels:
-      app: iot-mqtt-bridge
-  template:
-    metadata:
-      labels:
-        app: iot-mqtt-bridge
-    spec:
-      containers:
-        - name: mqtt-bridge
-          # Тот же образ что и оператор — оба бинаря в одном слое (manager + iot-mqtt-bridge).
-          # При смене версии оператора — менять тег и здесь.
-          image: pearlharbor.registryk8s.services.ngcloud.ru/naeel/sless-operator:v0.1.69
-          imagePullPolicy: Always
-          command: ["/iot-mqtt-bridge"]
-          env:
-            - name: MQTT_BROKER_URL
-              value: "tcp://emqx.sless.svc:1883"
-            - name: KAFKA_BROKERS
-              value: "kafka.sless.svc.cluster.local:9092"
-          envFrom:
-            - secretRef:
-                name: iot-bridge-credentials
-            # IOT_PG_DSN — сохранение телеметрии в Postgres (опционально)
-            - secretRef:
-                name: iot-postgres-secret
-                optional: true
-          resources:
-            requests:
-              memory: "32Mi"
-              cpu: "25m"
-            limits:
-              memory: "64Mi"
-              cpu: "100m"
-      imagePullSecrets:
-        - name: sless-registry-auth
@@ -1,66 +0,0 @@
-# Создано: 2026-04-05
-# Postgres для IoT телеметрии — отдельный от sless postgres (тот для invocations логов).
-# Deployment (не StatefulSet) — для dev/demo. В prod заменить на managed Postgres.
-#
-# Суперюзер iot_admin используется оператором для:
-#   - CREATE USER tenant_{ns} + CREATE DATABASE tenant_{ns}
-#   - CREATE TABLE iot_telemetry в tenant DB
-# Клиенты НЕ имеют прямого доступа — только через REST API платформы.
---
-apiVersion: v1
-kind: Secret
-metadata:
-  name: iot-postgres-secret
-  namespace: sless
-stringData:
-  # Суперпользователь — для управления tenant databases
-  POSTGRES_USER: "iot_admin"
-  POSTGRES_PASSWORD: "iot-pg-super-2026"
-  POSTGRES_DB: "iot_platform"
-  # DSN для оператора и mqtt-bridge (superuser к management DB)
-  IOT_PG_DSN: "postgresql://iot_admin:iot-pg-super-2026@iot-postgres.sless.svc:5432/iot_platform?sslmode=disable"
---
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: iot-postgres
-  namespace: sless
-  labels:
-    app: iot-postgres
-spec:
-  replicas: 1
-  selector:
-    matchLabels:
-      app: iot-postgres
-  template:
-    metadata:
-      labels:
-        app: iot-postgres
-    spec:
-      containers:
-        - name: postgres
-          image: postgres:16-alpine
-          ports:
-            - containerPort: 5432
-          envFrom:
-            - secretRef:
-                name: iot-postgres-secret
-          resources:
-            requests:
-              memory: "128Mi"
-              cpu: "100m"
-            limits:
-              memory: "512Mi"
-              cpu: "500m"
---
-apiVersion: v1
-kind: Service
-metadata:
-  name: iot-postgres
-  namespace: sless
-spec:
-  selector:
-    app: iot-postgres
-  ports:
-    - port: 5432
-      targetPort: 5432
@@ -1,150 +0,0 @@
-# Изменено: 2026-04-06 (добавлен postStart hook для предсоздания топика iot.telemetry)
-# kafka.yaml — минимальный деплой Apache Kafka в KRaft mode (без Zookeeper).
-# Образ: apache/kafka (официальный, бесплатный).
-# Используется для IoT telemetry pipeline: mqtt-bridge → Kafka → iot-kafka-consumer → Postgres.
-# Для prod: заменить на managed Kafka (Confluent/Aiven) — только изменить KAFKA_BROKERS в Secret.
---
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: kafka-config
-  namespace: sless
-data:
-  # server.properties для KRaft mode (без Zookeeper).
-  # Нода совмещает роли controller + broker.
-  server.properties: |
-    process.roles=broker,controller
-    node.id=1
-    controller.quorum.voters=1@localhost:9093
-    listeners=PLAINTEXT://:9092,CONTROLLER://:9093
-    inter.broker.listener.name=PLAINTEXT
-    controller.listener.names=CONTROLLER
-    listener.security.protocol.map=PLAINTEXT:PLAINTEXT,CONTROLLER:PLAINTEXT
-    advertised.listeners=PLAINTEXT://kafka.sless.svc.cluster.local:9092
-    log.dirs=/var/kafka-data/logs
-    num.partitions=1
-    default.replication.factor=1
-    offsets.topic.replication.factor=1
-    transaction.state.log.replication.factor=1
-    transaction.state.log.min.isr=1
-    log.retention.hours=168
-    log.retention.check.interval.ms=300000
-    auto.create.topics.enable=true
---
-apiVersion: apps/v1
-kind: StatefulSet
-metadata:
-  name: kafka
-  namespace: sless
-  labels:
-    app: kafka
-spec:
-  serviceName: kafka-headless
-  replicas: 1
-  selector:
-    matchLabels:
-      app: kafka
-  template:
-    metadata:
-      labels:
-        app: kafka
-    spec:
-      # apache/kafka образ запускается как UID 1000 (kafka user).
-      # fsGroup=1000 — позволяет писать в PVC смонтированный как root.
-      securityContext:
-        fsGroup: 1000
-      initContainers:
-        # Форматирует хранилище KRaft если ещё не отформатировано.
-        # KAFKA_CLUSTER_ID должен быть уникальным UUID — генерируется один раз.
-        - name: kafka-init
-          image: apache/kafka:3.7.0
-          command:
-            - /bin/sh
-            - -c
-            - |
-              if [ ! -f /var/kafka-data/logs/meta.properties ]; then
-                echo "Formatting Kafka storage..."
-                /opt/kafka/bin/kafka-storage.sh format \
-                  -t "$(cat /var/kafka-data/cluster.id 2>/dev/null || \
-                        /opt/kafka/bin/kafka-storage.sh random-uuid | tee /var/kafka-data/cluster.id)" \
-                  -c /tmp/kafka-config/server.properties
-              fi
-          volumeMounts:
-            - name: kafka-data
-              mountPath: /var/kafka-data
-            - name: kafka-config
-              mountPath: /tmp/kafka-config
-      containers:
-        - name: kafka
-          image: apache/kafka:3.7.0
-          command:
-            - /opt/kafka/bin/kafka-server-start.sh
-            - /tmp/kafka-config/server.properties
-          ports:
-            - containerPort: 9092
-              name: client
-            - containerPort: 9093
-              name: controller
-          resources:
-            requests:
-              cpu: 100m
-              memory: 256Mi
-            limits:
-              cpu: 500m
-              memory: 512Mi
-          volumeMounts:
-            - name: kafka-data
-              mountPath: /var/kafka-data
-            - name: kafka-config
-              mountPath: /tmp/kafka-config
-          readinessProbe:
-            tcpSocket:
-              port: 9092
-            initialDelaySeconds: 30
-            periodSeconds: 10
-            failureThreshold: 6
-      volumes:
-        - name: kafka-config
-          configMap:
-            name: kafka-config
-  volumeClaimTemplates:
-    - metadata:
-        name: kafka-data
-      spec:
-        accessModes: [ReadWriteOnce]
-        storageClassName: vcd-disk-ext4
-        resources:
-          requests:
-            storage: 1Gi
---
-apiVersion: v1
-kind: Service
-metadata:
-  name: kafka
-  namespace: sless
-  labels:
-    app: kafka
-spec:
-  ports:
-    - name: client
-      port: 9092
-      targetPort: 9092
-  selector:
-    app: kafka
---
-apiVersion: v1
-kind: Service
-metadata:
-  name: kafka-headless
-  namespace: sless
-  labels:
-    app: kafka
-spec:
-  clusterIP: None
-  ports:
-    - name: client
-      port: 9092
-    - name: controller
-      port: 9093
-  selector:
-    app: kafka
@@ -1,4 +1,4 @@
-# Изменено: 2026-04-06 (добавлены KAFKA_BROKERS, ADMIN_STATS_TOKEN, версия v0.1.70)
+# Изменено: 2026-03-21
 # Деплой sless оператора в кластер.
 # Состав:
 #   - ConfigMap: не-секретные env vars (S3_ENDPOINT, REGISTRY_HOST и т.д.)
@@ -33,8 +33,6 @@ data:
  # EXTERNAL_URL — если задан, URL функции = EXTERNAL_URL/fn/{namespace}/{name}
  # Позволяет обойтись без wildcard DNS *.fn.kube5s.ru
  EXTERNAL_URL: "https://sless.kube5s.ru"
-  # KAFKA_BROKERS — адрес Kafka для чтения consumer lag на странице администратора
-  KAFKA_BROKERS: "kafka.sless.svc.cluster.local:9092"
 ---
 # Secret создаётся отдельно через kubectl (не коммитить секреты в git!)
 # Описание ключей:
@@ -76,8 +74,7 @@ spec:
      containers:
        - name: operator
          # При обновлении версии оператора — менять тег здесь (не latest!)
-          # v0.1.59 — добавлено сохранение телеметрии в IoT Postgres (per-tenant DB)
-          image: pearlharbor.registryk8s.services.ngcloud.ru/naeel/sless-operator:v0.1.70
+          image: pearlharbor.registryk8s.services.ngcloud.ru/naeel/sless-operator:v0.1.49
          # Always — чтобы всегда тянуть по точному тегу (не кешировать старый)
          imagePullPolicy: Always
          ports:
@@ -92,15 +89,6 @@ spec:
                name: sless-operator-config
            - secretRef:
                name: sless-operator-secret
-            # IOT_PG_DSN — опциональный ключ: если не задан, IoT Postgres отключён
-            - secretRef:
-                name: iot-postgres-secret
-                optional: true
-          env:
-            # ADMIN_STATS_TOKEN — токен доступа к /iot-admin/stats (страница администратора).
-            # Менять на уникальный: kubectl set env deploy/sless-operator ADMIN_STATS_TOKEN=<token> -n sless
-            - name: ADMIN_STATS_TOKEN
-              value: "iot-admin-sless-2026"
          readinessProbe:
            httpGet:
              path: /healthz
@@ -1,4 +1,4 @@
-# Изменено: 2026-04-04 — добавлены IoT CRD права (iot.kube5s.ru)
+# Изменено: 2026-03-20 (добавлен Service CRD sless.kube5s.ru — services + status + finalizers)
 # RBAC для sless оператора.
 # ServiceAccount + ClusterRole + ClusterRoleBinding.
 # ClusterRole нужен (не namespaced Role) потому что оператор создаёт
@@ -15,7 +15,7 @@ kind: ClusterRole
 metadata:
  name: sless-operator
 rules:
-  # Наши CRD (sless.kube5s.ru)
+  # Наши CRD
  - apiGroups: ["sless.kube5s.ru"]
    resources: ["functions", "triggers", "functionjobs", "services"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
@@ -25,17 +25,6 @@ rules:
  - apiGroups: ["sless.kube5s.ru"]
    resources: ["functions/finalizers", "triggers/finalizers", "functionjobs/finalizers", "services/finalizers"]
    verbs: ["update"]
-  # IoT CRD (iot.kube5s.ru) — IoTDevice lifecycle + Secret генерация в контроллере
-  # Права нужны во всех namespace где пользователи создают IoT-устройства
-  - apiGroups: ["iot.kube5s.ru"]
-    resources: ["iotdevices"]
-    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
-  - apiGroups: ["iot.kube5s.ru"]
-    resources: ["iotdevices/status"]
-    verbs: ["get", "update", "patch"]
-  - apiGroups: ["iot.kube5s.ru"]
-    resources: ["iotdevices/finalizers"]
-    verbs: ["update"]
  # Deployments для функций
  - apiGroups: ["apps"]
    resources: ["deployments"]
@@ -1,219 +0,0 @@
-# ERR-PG-08: Concurrent Operations Not Supported
-
-## Problem Statement
-
-After completing an Update operation on `nubes_postgres` resource (e.g., vault_secrets refresh), attempting to create any dependent resource immediately fails with API 422 error:
-
-```
-Error: Ошибка клиента
-  ошибка API 422: {
-    "DETAIL": "There is a started operation on this instance",
-    "TYPE": "about:blank",
-    "TITLE": "Concurrent operations are not supported (job status: SUCCESS)"
-  }
-```
-
-Even though `WaitForOperation()` has returned successfully and the previous operation is marked as completed.
-
-## Reproduction
-
-1. Terraform plan detects vault_secrets has changed (external drift)
-2. Execute update: `nubes_postgres.pg_test_instance: Modifying...`
-3. Update completes: `nubes_postgres.pg_test_instance: Modifications complete after 0s`
-4. Immediately try to create: `nubes_postgres_database.pg_test_db: Creating...`
-5. **FAIL**: API returns 422 "Concurrent operations are not supported"
-
-## Why It Happens
-
-The Nubes API has an internal operation lock per instance. Even though the Update operation's `IsSuccessful` flag is true and operations are no longer in-progress, the API server is still processing asynchronous side effects:
- Vault credential updates
- Instance state synchronization
- Backend resource reconciliation
-
-When the next Create operation is submitted, the lock is still held, causing the 422 error.
-
-## Current Symptoms
-
- Affects: Any sequence where Update → Create operations happen on same instance
- Timing: Happens even with 120+ second waits
- Scope: Affects DB creation, user creation, any operation on PostgreSQL instance
- Test environment: Confirmed on `k8s-3-sandbox-nubes-ru` realm
- Production: Unknown (not tested)
-
-## Workarounds (Current)
-
-### Workaround 1: Split Resources Across Apply Cycles
-Comment out dependent resource creation, apply first update, then uncomment and apply again:
-
-```hcl
-# postgres.tf
-# temporarily comment out nubes_postgres_database block
-# terraform apply  ← creates pg_test_instance + users
-# uncomment nubes_postgres_database block
-# terraform apply  ← creates pg_test_db
-```
-
-Already implemented in this project (see [postgres.tf lines 87-99](../examples/PG_TEST/postgres.tf#L87-L99)).
-
-### Workaround 2: Add Explicit depends_on + relies on Terraform serialization
-```hcl
-resource "nubes_postgres_database" "pg_test_db" {
-  postgres_id = nubes_postgres.pg_test_instance.id
-  db_name     = var.pg_db_name
-  db_owner    = nubes_postgres_user.pg_test_user.username
-  
-  # Explicit depends_on forces sequential execution
-  # but does NOT help with concurrent operation lock
-  depends_on = [nubes_postgres_user.pg_test_user3]
-}
-```
-
-**Status**: Doesn't solve the problem - API still returns 422.
-
-### Workaround 3: Manual Sequential Runs
-```bash
-# First apply - creates instance and users
-terraform apply -auto-approve
-
-# Wait manually (or check instance state)
-sleep 180
-
-# Second apply - creates databases
-terraform apply -auto-approve
-```
-
-This is **unreliable** and not automatable.
-
-## Root Cause Analysis
-
-### Client-Side (Terraform Provider)
-
-**File**: [`internal/provider/client_impl.go`](../../terra/terraform/internal/provider/client_impl.go) line 240
-
-```go
-func (c *NubesClient) WaitForOperation(ctx context.Context, opUid string) error {
-    timeout := time.After(15 * time.Minute)
-    ticker := time.NewTicker(10 * time.Second)
-    // ...
-    
-    // Checks every 10 seconds for operation completion
-    if !op.IsInProgress && !op.IsPending && op.DtFinish != nil {
-        if op.IsSuccessful != nil && *op.IsSuccessful {
-            return nil  // ← Returns immediately when successful
-        }
-    }
-}
-```
-
-**Problem**: No post-completion delay or retry logic for subsequent operations.
-
-### Server-Side (Nubes API)
-
-The API maintains an operation lock on the instance that:
-1. Is released when operation completes (`IsSuccessful = true`)
-2. **But** async background tasks are still running during the lock release window
-3. New requests during this window: "There is a started operation on this instance"
-
-This is an **intentional safety measure** against corrupting instance state, but the window between "operation done" and "instance ready for next operation" is not deterministic.
-
-## Solutions (For Provider Fix)
-
-### Option 1: Add Post-Completion Delay
-**Pros**: Simple, guaranteed to work
-**Cons**: Always adds overhead, even if not needed
-
-```go
-// In client_impl.go, after "return nil" on success:
-if op.IsSuccessful != nil && *op.IsSuccessful {
-    // Add buffer for API server to release internal locks
-    time.Sleep(30 * time.Second)  // or configurable
-    return nil
-}
-```
-
-**Recommended value**: `30-60 seconds` based on observations.
-
-### Option 2: Implement Retry Mechanism
-**Pros**: No unnecessary delays, adapts to actual API response time
-**Cons**: More complex, needs careful timeout/backoff tuning
-
-When next operation fails with "concurrent operations", retry with exponential backoff:
-```go
-func (c *NubesClient) CreateResourceWithRetry(ctx context.Context, payload map[string]interface{}) error {
-    maxRetries := 5
-    backoff := 10 * time.Second
-    
-    for i := 0; i < maxRetries; i++ {
-        err := c.Create(ctx, payload)
-        if err == nil {
-            return nil
-        }
-        if strings.Contains(err.Error(), "Concurrent operations") {
-            time.Sleep(backoff)
-            backoff *= 2  // exponential backoff
-            continue
-        }
-        return err
-    }
-}
-```
-
-**Backoff suggestion**: Start 10s, cap at 60s.
-
-### Option 3: Query Instance State Before Next Operation
-**Pros**: Most elegant, confirms instance is ready
-**Cons**: Requires additional API call, might still be unreliable
-
-```go
-func (c *NubesClient) WaitForInstanceReady(ctx context.Context, instanceId string) error {
-    // Poll instance state directly, not just operation state
-    for retry := 0; retry < 30; retry++ {
-        state, err := c.GetInstanceState(ctx, instanceId)
-        if err == nil && state.IsReady {
-            return nil
-        }
-        time.Sleep(5 * time.Second)
-    }
-    return fmt.Errorf("instance not ready after timeout")
-}
-```
-
-## Recommendation
-
-**Implement Option 1 (Post-Completion Delay)** combined with **Option 2 (Retry Logic)**:
-
-1. Add fixed 30-second delay after `WaitForOperation` returns success (**fail-safe**)
-2. Keep retry mechanism for cases where clients don't respect the delay (**defensive**)
-
-This provides both reliability (fixed delay) and robustness (retry on failure).
-
-## Testing
-
-**Test case**:
-```bash
-cd examples/PG_TEST
-
-# Uncomment pg_test_db in postgres.tf
-terraform apply -auto-approve
-
-# Should NOT fail with 422 "Concurrent operations are not supported"
-# Should create all 3 resources: instance, users, database
-```
-
-**Current status**: ❌ FAILS with 422
-
-**After fix**: ✅ SHOULD PASS
-
-## References
-
- Provider source: `/home/naeel/terra/terraform/internal/provider/`
- Test configuration: `/home/naeel/terra/sless/examples/PG_TEST/`
- Related: ERR-PG-02 (fixed), ERR-PG-03 (race condition), ERR-PG-04 (invalid role)
- Vault credentials: Not involved in this error (different subsystem)
-
---
-
-**Date discovered**: 2026-04-03  
-**Status**: Open, blocker for multi-resource deployments  
-**Priority**: High (blocks full lifecycle automation)  
-**Scope**: Test environment confirmed, production unknown
@@ -1,170 +0,0 @@
-# Session Report: PostgreSQL Discovery - April 3, 2026
-
-## Session Overview
-
-**Duration**: Single session, April 3, 2026  
-**Focus**: Root cause analysis of PostgreSQL terraform lifecycle tests failures  
-**Outcome**: 2 major problems identified and documented
-
---
-
-## Key Findings
-
-### 1. ERR-PG-02: FIXED ✅
-
-**Previously**: ID going to `(known after apply)` during Update operations
-
-**Status**: Already fixed in current provider code (`internal/provider/postgres_resource.go` line ~845)
- Code now explicitly preserves ID from state during Update
- No longer reproducible - no destroy+recreate of dependent resources
-
-**Verification**: `terraform plan` shows `0 to destroy` (correct behavior)
-
---
-
-### 2. ERR-PG-06: RECLASSIFIED 🔄
-
-**Previously**: Claimed that only 1 user per PostgreSQL instance could be created with vault_secrets
-
-**Corrected Finding**: Multiple users work fine when properly configured
- Successfully created `pg_test_user` (user0) and `pg_test_user3` (u3)
- Both have vault_secrets successfully populated
-
-**Root Cause of Original Error**: Lack of `depends_on` between user resources → race condition in Vault writes
-
-**Solution**: Strict `depends_on` chain between users is required and works perfectly
-
---
-
-### 3. ERR-PG-08: NEW PROBLEM ❌
-
-**Description**: After Update operation completes (even successfully), creating dependent resources fails with 422 "Concurrent operations are not supported"
-
-**Symptoms**:
-```
-Error: Ошибка клиента
-  ошибка API 422: {
-    "TITLE": "Concurrent operations are not supported (job status: SUCCESS)"
-  }
-```
-
-**Root Cause**: Nubes API maintains internal lock on instance even after operation completion. Post-operation async tasks (Vault sync, state reconciliation) still run.
-
-**Impact**: Cannot create databases or additional users immediately after instance update in same Terraform apply
-
-**Workaround Found**: Split apply into phases (comment out DB resource, apply, uncomment, apply again)
-
-**Requires**: Provider fix - add post-completion delay or retry mechanism in `WaitForOperation()` method
-
---
-
-## Documentation Created
-
-1. **[/home/naeel/remote_dev/sless/doc/ERR-PG-08-concurrent-operations.md](./ERR-PG-08-concurrent-operations.md)**
-   - Detailed problem analysis
-   - 3 solution options (fixed delay, retry mechanism, instance state query)
-   - Recommendation: combine options 1 + 2
-
-2. **Updated [/home/naeel/remote_dev/sless/doc/errors/log.md](./errors/log.md)**
-   - Added corrections to ERR-PG-06 (multi-user now works)
-   - Added new section for ERR-PG-08 (concurrent ops limitation)
-
-3. **Updated [/home/naeel/remote_dev/sless/doc/pg-terraform-behavior.md](./pg-terraform-behavior.md)**
-   - Table (section 6) updated: shows 2nd/3rd user creation now works
-   - Added section 3.5: detailed ERR-PG-08 explanation
-   - Corrected: "2 users per instance" now says "Works with depends_on"
-
---
-
-## Terraform Configuration Status
-
-**Current Setup** (`examples/PG_TEST`):
- ✅ `nubes_postgres` instance created successfully
- ✅ `pg_test_user` (user0) created successfully  
- ✅ `pg_test_user3` (u3) created successfully
- ❌ `pg_test_db` cannot be created (blocked by ERR-PG-08)
-
-**Workaround Applied**:
- [x] Commented out `nubes_postgres_database` resource block (lines 87-99)
- [x] Updated outputs.tf to disable database-dependent outputs
- [x] Successfully applied (0 added, 1 changed, 0 destroyed)
-
-**Status**: Awaiting provider fix to re-enable database creation
-
---
-
-## Provider Source Files
-
-**Identified locations** for fix:
- `/home/naeel/terra/terraform/internal/provider/client_impl.go` line 240
-  - `WaitForOperation()` method needs post-completion handling
-  - Current: returns immediately on `IsSuccessful = true`
-  - Needed: add delay or retry mechanism
-
- `/home/naeel/terra/terraform/internal/provider/postgres_resource.go` line 617+
-  - Update() method (already has ERR-PG-02 fix)
-  - Would benefit from handling ERR-PG-08 retries
-
---
-
-## Next Steps (For Future Sessions)
-
-1. **Priority FIX**: Implement post-completion delay in `WaitForOperation()`
-   - Add 30-60 second sleep after success return
-   - Or implement exponential backoff retry for 422 errors
-
-2. **Testing**: After fix applied
-   - Re-enable `nubes_postgres_database` in postgres.tf
-   - Verify `terraform apply` succeeds fully (0 destroyed)
-   - Run stress tests with multiple users and databases
-
-3. **Documentation**: After fix verified
-   - Update `pg-terraform-behavior.md` table (remove ERR-PG-08 workaround)
-   - Mark ERR-PG-08 as "FIXED"
-   - Update provider-fix-plan.md with implementation details
-
-4. **Codebase**: Commit changes
-   - Provider fix in `/home/naeel/terra/terraform/`
-   - Documentation updates in `/home/naeel/remote_dev/sless/`
-
---
-
-## Files Modified This Session
-
-### In `/home/naeel/remote_dev/sless/`
-
- ✅ [doc/ERR-PG-08-concurrent-operations.md](./doc/ERR-PG-08-concurrent-operations.md) — CREATED (new)
- ✅ [doc/errors/log.md](./doc/errors/log.md) — UPDATED (added corrections + ERR-PG-08)
- ✅ [doc/pg-terraform-behavior.md](./doc/pg-terraform-behavior.md) — UPDATED (table + section 3.5)
- ⚠️ [examples/PG_TEST/postgres.tf](./examples/PG_TEST/postgres.tf) — MODIFIED (commented out DB)
- ⚠️ [examples/PG_TEST/outputs.tf](./examples/PG_TEST/outputs.tf) — MODIFIED (disabled DB outputs)
-
-### On VM `/home/naeel/terra/`
-
- No code changes (only investigation)
- Terraform state reflects multi-user success
- Provider source examined but not modified
-
---
-
-## Lessons Learned
-
-1. **Multi-user creation works** when using proper `depends_on` chains
-2. **Vault limitation hypothesis was wrong** - it was a race condition issue
-3. **Concurrent operations limit is real** and requires provider-level fix
-4. **Provider already has one fix** (ERR-PG-02 id preservation) - shows active maintenance
-5. **Test environment is functional** despite appearing to fail initially
-
---
-
-## Technical Debt
-
- [ ] ERR-PG-08 requires provider fix (not blocking test framework, blocking full automation)
- [ ] Consider: Is concurrent operations lock intentional safety feature? Document if so.
- [ ] Consider: Add configurable retry delays for production resilience
-
---
-
-**Session Status**: COMPLETE - Major findings documented, actionable recommendations provided
-
-**Ready For**: Next programmer to implement provider fix based on documented analysis
@@ -1,74 +1,32 @@
 # Архитектура системы

-Последнее обновление: 2026-04-04 (IoT telemetry storage architecture decision)
+Последнее обновление: 2026-03-18 (v0.1.34 + funcs-service v0.2.0)

 ## Общее описание

-Managed Serverless Functions Service + IoT Platform для облачного провайдера nubes.ru.
-Два независимых компонента: sless (serverless) и iot (IoT), каждый со своим оператором.
+Managed Serverless Functions Service для облачного провайдера nubes.ru.
 Пользователь загружает код через Terraform, сервис его собирает (kaniko) и запускает
-по HTTP-триггеру, расписанию (cron), вручную или по событию от IoT устройства.
-
-## Namespace Layout
-
-```
-namespace: sless          — платформа serverless
-                            (sless-operator, event-dispatcher, RabbitMQ, Postgres invocations)
-namespace: sless-{hash}   — tenant функции (function pods каждого клиента)
-namespace: iot            — платформа IoT
-                            (iot-operator, EMQX, Postgres telemetry)
-namespace: iot-{hash}     — tenant IoT ресурсы (IoTDevice CRDs)
-```
+по HTTP-триггеру, расписанию (cron) или вручную через one-shot Job.

 ## Стек

 | Компонент | Технология | Где запущен |
 |-----------|-----------|-------------|
-| sless-operator (API + Controllers) | Go (controller-runtime) | namespace `sless` |
-| iot-operator (API + Controllers) | Go (controller-runtime) | namespace `iot` |
-| PostgreSQL (invocations) | PostgreSQL 16 | namespace `sless` |
-| PostgreSQL (telemetry) | PostgreSQL 16 | namespace `iot` |
-| EMQX | EMQX 5.5.1 | namespace `iot` |
-| RabbitMQ | RabbitMQ 3 | namespace `sless` |
-| event-dispatcher | Go | namespace `sless` |
-| iot-mqtt-bridge | Go | namespace `iot` |
+| Operator (API + Controllers) | Go (controller-runtime) | Kubernetes, namespace `sless` |
+| funcs-service (глобальная консоль) | Go (net/http) | Kubernetes, namespace `sless` |
+| PostgreSQL | PostgreSQL 16 | Kubernetes, namespace `sless` |
 | S3 | Ceph (облачный) | `s3.msk-1.ngcloud.ru` |
-| Container Registry | PearlHarbor (Nubes) | внешний |
+| Container Registry | DockerHub (`naeel/`) | внешний |
 | Builder | kaniko (k8s Job) | namespace пользователя |
-| Функции (HTTP) | k8s Deployment + Service | namespace sless-{hash} |
-| Функции (one-shot) | k8s Job | namespace sless-{hash} |
-| Функции (cron) | k8s CronJob | namespace sless-{hash} |
+| Функции (HTTP) | k8s Deployment + Service | namespace пользователя |
+| Функции (one-shot) | k8s Job | namespace пользователя |
+| Функции (cron) | k8s CronJob | namespace пользователя |
 | Terraform Provider | Go (plugin framework v6) | localhost/CI |
 | nubes API | REST (облако) | `deck-api.ngcloud.ru` |

-## IoT Data Flow
+> Redis и RabbitMQ — отложены до v2.

-```
-IoT устройство
-    ↓ ws://iot.kube5s.ru:80/mqtt (WebSocket, пока 1883 закрыт)
-EMQX (namespace iot)
-    ↓ ACL: каждое устройство видит только свои топики {ns}/{deviceId}/#
-iot-mqtt-bridge
-    ↓
-RabbitMQ (namespace sless)
-    ↓
-event-dispatcher
-    ↓ параллельно:
-    1. INSERT INTO tenant_{ns}.iot_telemetry  ← автоматически
-    2. Вызов serverless function (если настроена)
-```
-
-## Изоляция данных
-
- MQTT: ACL по username → топики только своего устройства
- Postgres: отдельная DATABASE per tenant, разные credentials
- k8s: отдельный namespace per tenant
-
-## Связь sless ↔ iot
-
- Общий идентификатор tenant: `{hash}` в именах namespace
- Коммуникация через RabbitMQ endpoint (не через Go пакеты)
- Loose coupling — могут быть в разных кластерах
+## Компонент: funcs-service

 Глобальный HTTP сервис — **одна копия** на весь кластер, для всех пользователей.

@@ -1,135 +0,0 @@
-<svg xmlns="http://www.w3.org/2000/svg" width="900" height="700" font-family="Arial, sans-serif" font-size="13">
-
-  <!-- Background -->
-  <rect width="900" height="700" fill="#f8f9fa" rx="10"/>
-
-  <!-- Title -->
-  <text x="450" y="32" text-anchor="middle" font-size="18" font-weight="bold" fill="#1a1a2e">SQS Operator — ресурсы на тенанта</text>
-
-  <!-- === QueueService CR === -->
-  <rect x="340" y="55" width="220" height="55" rx="8" fill="#4a90d9" stroke="#2c6fad" stroke-width="1.5"/>
-  <text x="450" y="77" text-anchor="middle" fill="white" font-weight="bold">📋 QueueService CR</text>
-  <text x="450" y="97" text-anchor="middle" fill="#dce9f8" font-size="11">tenant: test001 · enableUI: true</text>
-
-  <!-- Arrow CR -> Operator -->
-  <line x1="450" y1="110" x2="450" y2="145" stroke="#666" stroke-width="1.5" marker-end="url(#arr)"/>
-  <text x="460" y="132" fill="#666" font-size="11">reconcile</text>
-
-  <!-- === Operator === -->
-  <rect x="310" y="145" width="280" height="50" rx="8" fill="#7c3aed" stroke="#5b21b6" stroke-width="1.5"/>
-  <text x="450" y="166" text-anchor="middle" fill="white" font-weight="bold">⚙️ Оператор</text>
-  <text x="450" y="184" text-anchor="middle" fill="#e9d5ff" font-size="11">QueueServiceReconciler (Go)</text>
-
-  <!-- === Namespace box === -->
-  <rect x="30" y="235" width="840" height="430" rx="10" fill="white" stroke="#94a3b8" stroke-width="1.5" stroke-dasharray="6,3"/>
-  <text x="50" y="258" fill="#64748b" font-size="12" font-weight="bold">Namespace: sless-fn-test001</text>
-
-  <!-- Arrow Operator -> Namespace -->
-  <line x1="450" y1="195" x2="450" y2="235" stroke="#666" stroke-width="1.5" marker-end="url(#arr)"/>
-  <text x="460" y="220" fill="#666" font-size="11">creates</text>
-
-  <!-- === Row 1: Secret, ConfigMap, PVC === -->
-  <!-- Secret -->
-  <rect x="55" y="270" width="180" height="60" rx="7" fill="#059669" stroke="#047857" stroke-width="1.5"/>
-  <text x="145" y="293" text-anchor="middle" fill="white" font-weight="bold">🔑 Secret</text>
-  <text x="145" y="311" text-anchor="middle" fill="#d1fae5" font-size="11">sqs-creds-test001</text>
-  <text x="145" y="325" text-anchor="middle" fill="#d1fae5" font-size="10">access_key / secret_key</text>
-
-  <!-- ConfigMap -->
-  <rect x="260" y="270" width="180" height="60" rx="7" fill="#d97706" stroke="#b45309" stroke-width="1.5"/>
-  <text x="350" y="293" text-anchor="middle" fill="white" font-weight="bold">📄 ConfigMap</text>
-  <text x="350" y="311" text-anchor="middle" fill="#fef3c7" font-size="11">sqs-cfg-test001</text>
-  <text x="350" y="325" text-anchor="middle" fill="#fef3c7" font-size="10">elasticmq.conf</text>
-
-  <!-- PVC -->
-  <rect x="465" y="270" width="180" height="60" rx="7" fill="#0891b2" stroke="#0e7490" stroke-width="1.5"/>
-  <text x="555" y="293" text-anchor="middle" fill="white" font-weight="bold">💾 PVC</text>
-  <text x="555" y="311" text-anchor="middle" fill="#cffafe" font-size="11">sqs-data-test001</text>
-  <text x="555" y="325" text-anchor="middle" fill="#cffafe" font-size="10">H2 persistence (остаётся при удалении CR)</text>
-
-  <!-- === Deployment === -->
-  <rect x="55" y="365" width="840" height="0" rx="0" fill="none"/>
-
-  <!-- Deployment box -->
-  <rect x="160" y="360" width="380" height="120" rx="9" fill="#f1f5f9" stroke="#475569" stroke-width="2"/>
-  <text x="350" y="380" text-anchor="middle" fill="#334155" font-weight="bold" font-size="12">🚀 Deployment: sqs-test001</text>
-
-  <!-- Container ElasticMQ -->
-  <rect x="175" y="390" width="160" height="75" rx="6" fill="#e2e8f0" stroke="#64748b" stroke-width="1"/>
-  <text x="255" y="410" text-anchor="middle" fill="#1e293b" font-weight="bold" font-size="11">ElasticMQ</text>
-  <text x="255" y="427" text-anchor="middle" fill="#475569" font-size="10">port 9324</text>
-  <text x="255" y="442" text-anchor="middle" fill="#475569" font-size="10">Scala / Akka HTTP</text>
-  <text x="255" y="457" text-anchor="middle" fill="#64748b" font-size="10">elasticmq:1.7.1</text>
-
-  <!-- Container UI -->
-  <rect x="355" y="390" width="170" height="75" rx="6" fill="#e2e8f0" stroke="#64748b" stroke-width="1"/>
-  <text x="440" y="410" text-anchor="middle" fill="#1e293b" font-weight="bold" font-size="11">elasticmq-ui</text>
-  <text x="440" y="427" text-anchor="middle" fill="#475569" font-size="10">port 3000</text>
-  <text x="440" y="442" text-anchor="middle" fill="#475569" font-size="10">Next.js</text>
-  <text x="440" y="457" text-anchor="middle" fill="#64748b" font-size="10">elasticmq-ui:latest</text>
-
-  <!-- Arrows ConfigMap/PVC -> Deployment -->
-  <line x1="350" y1="330" x2="350" y2="360" stroke="#b45309" stroke-width="1.5" stroke-dasharray="4,2" marker-end="url(#arr)"/>
-  <line x1="555" y1="330" x2="430" y2="360" stroke="#0e7490" stroke-width="1.5" stroke-dasharray="4,2" marker-end="url(#arr)"/>
-  <text x="470" y="350" fill="#64748b" font-size="10">mount</text>
-
-  <!-- === Service === -->
-  <rect x="600" y="380" width="200" height="65" rx="7" fill="#6366f1" stroke="#4f46e5" stroke-width="1.5"/>
-  <text x="700" y="403" text-anchor="middle" fill="white" font-weight="bold">🔌 Service ClusterIP</text>
-  <text x="700" y="421" text-anchor="middle" fill="#e0e7ff" font-size="11">sqs-svc-test001</text>
-  <text x="700" y="437" text-anchor="middle" fill="#e0e7ff" font-size="11">9324 (SQS) · 3000 (UI)</text>
-
-  <!-- Arrow Deployment -> Service -->
-  <line x1="540" y1="415" x2="600" y2="415" stroke="#666" stroke-width="1.5" marker-end="url(#arr)"/>
-
-  <!-- === Ingresses === -->
-  <!-- ING1 -->
-  <rect x="55" y="520" width="185" height="65" rx="7" fill="#db2777" stroke="#be185d" stroke-width="1.5"/>
-  <text x="147" y="543" text-anchor="middle" fill="white" font-weight="bold">🌐 Ingress SQS API</text>
-  <text x="147" y="560" text-anchor="middle" fill="#fce7f3" font-size="10">sqs-ing-test001</text>
-  <text x="147" y="575" text-anchor="middle" fill="#fce7f3" font-size="10">/sqs/test001/... → :9324</text>
-
-  <!-- ING2 -->
-  <rect x="260" y="520" width="185" height="65" rx="7" fill="#db2777" stroke="#be185d" stroke-width="1.5"/>
-  <text x="352" y="543" text-anchor="middle" fill="white" font-weight="bold">🌐 Ingress UI</text>
-  <text x="352" y="560" text-anchor="middle" fill="#fce7f3" font-size="10">sqs-ing-ui-test001</text>
-  <text x="352" y="575" text-anchor="middle" fill="#fce7f3" font-size="10">/sqs-ui/test001/ → :3000</text>
-
-  <!-- ING3 -->
-  <rect x="465" y="520" width="185" height="65" rx="7" fill="#db2777" stroke="#be185d" stroke-width="1.5"/>
-  <text x="557" y="543" text-anchor="middle" fill="white" font-weight="bold">🌐 Ingress Assets</text>
-  <text x="557" y="560" text-anchor="middle" fill="#fce7f3" font-size="10">sqs-ing-ui-assets-test001</text>
-  <text x="557" y="575" text-anchor="middle" fill="#fce7f3" font-size="10">/_next/ → :3000</text>
-
-  <!-- ING4 -->
-  <rect x="670" y="520" width="185" height="65" rx="7" fill="#db2777" stroke="#be185d" stroke-width="1.5"/>
-  <text x="762" y="543" text-anchor="middle" fill="white" font-weight="bold">🌐 Ingress Routes</text>
-  <text x="762" y="560" text-anchor="middle" fill="#fce7f3" font-size="10">sqs-ing-ui-queues-test001</text>
-  <text x="762" y="575" text-anchor="middle" fill="#fce7f3" font-size="10">/queues/ → :3000</text>
-
-  <!-- Arrows Service -> Ingresses -->
-  <line x1="700" y1="445" x2="700" y2="490" stroke="#4f46e5" stroke-width="1" stroke-dasharray="4,2"/>
-  <line x1="700" y1="490" x2="147" y2="490" stroke="#4f46e5" stroke-width="1" stroke-dasharray="4,2"/>
-  <line x1="147" y1="490" x2="147" y2="520" stroke="#4f46e5" stroke-width="1" marker-end="url(#arr)"/>
-  <line x1="352" y1="490" x2="352" y2="520" stroke="#4f46e5" stroke-width="1" marker-end="url(#arr)"/>
-  <line x1="557" y1="490" x2="557" y2="520" stroke="#4f46e5" stroke-width="1" marker-end="url(#arr)"/>
-  <line x1="700" y1="490" x2="762" y2="490" stroke="#4f46e5" stroke-width="1" stroke-dasharray="4,2"/>
-  <line x1="762" y1="490" x2="762" y2="520" stroke="#4f46e5" stroke-width="1" marker-end="url(#arr)"/>
-
-  <!-- Client -->
-  <rect x="340" y="630" width="220" height="45" rx="8" fill="#1a1a2e" stroke="#334155" stroke-width="1.5"/>
-  <text x="450" y="650" text-anchor="middle" fill="white" font-weight="bold">🖥️ Browser / AWS SDK</text>
-  <text x="450" y="667" text-anchor="middle" fill="#94a3b8" font-size="11">sqs.kube5s.ru (HTTPS)</text>
-
-  <!-- Arrow Client -> Ingresses -->
-  <line x1="380" y1="630" x2="200" y2="588" stroke="#6b7280" stroke-width="1.5" marker-end="url(#arr)"/>
-  <line x1="450" y1="630" x2="420" y2="588" stroke="#6b7280" stroke-width="1.5" marker-end="url(#arr)"/>
-
-  <!-- Arrow marker -->
-  <defs>
-    <marker id="arr" markerWidth="8" markerHeight="8" refX="6" refY="3" orient="auto">
-      <path d="M0,0 L0,6 L8,3 z" fill="#666"/>
-    </marker>
-  </defs>
-
-</svg>
@@ -1,174 +0,0 @@
-# Решение: IoT Telemetry Storage Architecture
-# Дата: 2026-04-04
-# Агент: GitHub Copilot (Claude Sonnet 4.6)
-# Статус: ПРИНЯТО
-
---
-
-## Контекст
-
-IoT платформа принимает данные с датчиков через MQTT. Данные проходят:
-EMQX → iot-mqtt-bridge → RabbitMQ → event-dispatcher → function pod.
-
-Проблема: данные не сохраняются. Функция получает событие и забывает его.
-Для клиентов (мониторинг объектов, счётчики, производство) нужно:
- Автоматическое хранение всей телеметрии
- Доступ к историческим данным
- Низкий порог входа — не требовать от клиента настройки БД
-
---
-
-## Решения
-
-### 1. Хранилище — Postgres, отдельная DATABASE per tenant
-
-**Выбрано**: один Postgres инстанс, отдельная DATABASE на каждого клиента.
-
-**Отклонено**: одна таблица с tenant_id колонкой.
- Причина: изоляция только программная. Ошибка в WHERE → утечка чужих данных.
-
-**Структура**:
-```
-Postgres (StatefulSet в namespace iot)
-├── sless_platform   — системные данные платформы (tenants, etc)
-├── tenant_{hash}    — данные клиента A (полная изоляция)
-└── tenant_{hash}    — данные клиента B (полная изоляция)
-```
-
-**Безопасность**:
- Каждый tenant имеет свой Postgres USER с уникальным паролем (UUID)
- Пароль генерируется при создании tenant, хранится в k8s Secret
- Клиент B физически не может подключиться к DATABASE клиента A
-
---
-
-### 2. Доступ клиента — только через REST API
-
-**Выбрано**: клиент читает телеметрию через REST API платформы.
-
-**Отклонено**: прямой доступ к Postgres через connection string.
- Причина: Postgres внутри кластера, не должен торчать наружу. Security.
-
-**API**:
-```
-GET /v1/namespaces/{ns}/iot/telemetry
-    ?device={device_id}
-    &from={RFC3339}
-    &to={RFC3339}
-    &limit={int}
-
-GET /v1/namespaces/{ns}/iot/devices/{id}/last
-```
-
-Авторизация — Bearer токен (тот же механизм что и для functions).
-
---
-
-### 3. Схема таблицы telemetry
-
-```sql
-CREATE TABLE iot_telemetry (
-    id        BIGSERIAL PRIMARY KEY,
-    device_id TEXT        NOT NULL,
-    ts        TIMESTAMPTZ NOT NULL DEFAULT now(),
-    payload   JSONB       NOT NULL
-);
-
-CREATE INDEX idx_iot_telemetry_device_ts
-    ON iot_telemetry (device_id, ts DESC);
-```
-
-**Почему JSONB**: у каждого клиента разные наборы данных:
- датчик температуры: `{"temp": 22.5, "humidity": 60}`
- GPS трекер: `{"lat": 55.75, "lon": 37.61, "speed": 60}`
- счётчик воды: `{"liters": 1234.5, "flow": 0.3}`
-
-Фиксированная схема невозможна. JSONB + индекс по (device_id, ts) даёт
-достаточную производительность для малого и среднего бизнеса.
-
---
-
-### 4. schema.sql при деплое функции
-
-Клиент может положить `schema.sql` рядом с функцией:
-```
-my-function/
-├── handler.py
-├── schema.sql    ← CREATE TABLE IF NOT EXISTS my_alerts (...)
-└── requirements.txt
-```
-
-При деплое оператор выполняет `schema.sql` в БД tenant'а.
-Это позволяет клиентам без знания Python настраивать дополнительные таблицы.
-
---
-
-### 5. DB_DSN в функцию
-
-При запуске function pod оператор прокидывает `DB_DSN` из Secret в env var:
-```
-DB_DSN=postgresql://tenant_abc:password@iot-postgres.iot.svc:5432/tenant_abc
-```
-
-Функция использует стандартный драйвер, не знает о деталях платформы.
-
---
-
-### 6. Разделение sless и iot операторов
-
-**Решение**: sless-operator и iot-operator — ОТДЕЛЬНЫЕ компоненты с раздельными namespace.
-
-**Мотивация**:
- В будущем могут быть в разных кластерах
- Независимый деплой и масштабирование
- Разные команды могут владеть компонентами
- Нет cross-dependency в коде (loose coupling)
-
-**Namespace layout**:
-```
-namespace: sless          — платформа serverless
-                            (sless-operator, event-dispatcher, RabbitMQ, Postgres invocations)
-namespace: sless-{hash}   — tenant функции (function pods каждого клиента)
-
-namespace: iot            — платформа IoT
-                            (iot-operator, EMQX, Postgres telemetry)
-namespace: iot-{hash}     — tenant IoT ресурсы (IoTDevice CRDs)
-```
-
-**Связь между sless и iot**:
- Общий идентификатор tenant: `{hash}` одинаковый в sless-{hash} и iot-{hash}
- MQTT событие → RabbitMQ в namespace sless → function pod в sless-{hash}
- iot-operator НЕ импортирует Go пакеты sless-operator
- Общение только через k8s API и RabbitMQ endpoints
-
-**Postgres**:
- sless: отдельный Postgres для invocations логов
- iot: отдельный Postgres для telemetry per-tenant
- Разные StatefulSet, разные PVC, разные credentials
-
---
-
-### 7. Postgres инстанс для IoT
-
-**Выбрано**: `postgres:16-alpine` StatefulSet в namespace `iot`.
-
-**Причина**: простота для разработки. При передаче в production девопсы
-заменят на Managed Postgres от Nubes — connection string поменяется, код не меняется.
-
-**Ресурсы**:
- PVC: 10Gi (начальный размер, увеличивается по мере роста)
- Memory limit: 512Mi
- CPU: 0.5 cores
-
---
-
-## План реализации
-
-1. StatefulSet Postgres в namespace `iot`
-2. iot-operator: provisioning при создании IoTDevice namespace
-   - CREATE USER tenant_{ns} PASSWORD '{uuid}'
-   - CREATE DATABASE tenant_{ns} OWNER tenant_{ns}
-   - CREATE TABLE iot_telemetry + индекс
-3. iot-mqtt-bridge: INSERT telemetry при получении MQTT сообщения
-4. iot-operator: REST API `/v1/namespaces/{ns}/iot/telemetry`
-5. sless-operator: при деплое function → прокинуть DB_DSN + выполнить schema.sql
@@ -1,500 +0,0 @@
-# План-инструкция: sless_job функции для установки ПО в ВМ
-
-> 2026-03-29 — Инструкция для AI-агента (GPT/Claude/Codex).
-> Цель: демонстрация заказчику связки Terraform + Serverless.
-> Один `terraform apply` — поднимается vApp/VM + автоматически устанавливается ПО.
-
---
-
-## Контекст: что уже есть
-
-```
-examples/VM/
-├── main.tf          # provайдер nubes, переменные (api_token, vm_public_key)
-├── vapp.tf          # nubes_vapp.vapp — контейнер ВМ
-├── vm.tf            # nubes_vc_vm_v3.vm — Ubuntu 22.04, 2CPU/2GB/20GB
-├── terraform.tfvars # токены (gitignored)
-├── vm_key / vm_key.pub  # SSH-ключ для ВМ
-└── .terraform/      # init уже выполнен
-```
-
-**ВМ поднята и работает.** IP: `nubes_vc_vm_v3.vm.state_out_flat["externalConnect"]`.
-SSH: `ssh -i vm_key ubuntu@<IP>`.
-
-Платформа sless поднята: оператор v0.1.62, API `https://sless.kube5s.ru`.
-
---
-
-## Что нужно сделать
-
-Добавить в `examples/VM/` sless-провайдер и набор `sless_job` ресурсов, которые по SSH
-устанавливают ПО на ВМ. Пользователь шаблона включает нужные флагами.
-
-### Целевой результат для заказчика
-
-```bash
-cd examples/VM
-# пользователь выставляет флаги:
-#   install_docker   = true
-#   install_postgres = true
-terraform apply
-# → vApp + VM создаются (или уже есть)
-# → джобы подключаются по SSH и ставят Docker, PostgreSQL и т.д.
-# → outputs показывают статус каждого шага
-```
-
---
-
-## Архитектура: СТРОГО sless_job
-
- Каждая установка = отдельный `sless_job` (one-shot, execution task).
- НЕ создавать `sless_service` (у функций-установщиков нет постоянного URL).
- НЕ создавать новый Terraform resource — только `sless_job`.
- Передача параметров: `env_vars` — для подключения (IP, ключ), `event_json` — для бизнес-логики.
-
---
-
-## Файловая структура (целевая)
-
-```
-examples/VM/
-├── main.tf                 # + добавить provider "sless"
-├── vapp.tf                 # без изменений
-├── vm.tf                   # без изменений
-├── variables.tf            # NEW — все переменные (включая флаги install_*)
-├── sless.tf                # NEW — provider sless + sless_job ресурсы
-├── outputs.tf              # NEW — outputs статусов джобов
-├── terraform.tfvars        # + добавить sless_token, флаги
-│
-├── functions/              # NEW — код функций-установщиков
-│   ├── install-packages/
-│   │   ├── handler.py
-│   │   └── requirements.txt  # paramiko
-│   ├── install-docker/
-│   │   ├── handler.py
-│   │   └── requirements.txt
-│   └── install-postgres/
-│       ├── handler.py
-│       └── requirements.txt
-│
-├── vm_key / vm_key.pub
-└── .terraform/
-```
-
---
-
-## Контракт Python handler для sless_job
-
-```python
-# handler.py — загружается в контейнер как /app/function/handler.py
-# Рантайм: python3.11
-# Вызывается один раз, результат = JSON → записывается в job.message
-
-import os
-
-def install(event):
-    """
-    event — dict из event_json Terraform-ресурса.
-    os.environ — содержит env_vars из Terraform-ресурса.
-    
-    Возврат:
-      dict/list → JSON (phase=Succeeded, message=json)
-      raise Exception → phase=Failed, message=traceback
-    """
-    vm_ip    = os.environ["VM_IP"]
-    ssh_user = os.environ["SSH_USER"]
-    ssh_key  = os.environ["SSH_KEY"]    # содержимое приватного ключа (PEM)
-    
-    packages = event.get("packages", [])
-    
-    # ... SSH + установка ...
-    
-    return {"status": "ok", "installed": packages}
-```
-
---
-
-## Спецификация каждой функции
-
-### 1. install-packages (Этап A — первый)
-
-**Назначение:** Универсальный apt-установщик. Ставит произвольный список пакетов.
-
-**handler.py** — entrypoint: `handler.install`
-
-```
-event_json:
-  packages: ["git", "curl", "htop", "..."]     # обязательно — список имён пакетов apt
-  update: true                                   # опционально — apt update перед install (default: true)
-
-env_vars:
-  VM_IP:    nubes_vc_vm_v3.vm.state_out_flat["externalConnect"]
-  SSH_USER: "ubuntu"
-  SSH_KEY:  file("${path.module}/vm_key")
-
-requirements.txt:
-  paramiko
-```
-
-**Логика:**
-1. Подключиться по SSH через paramiko (ключ из env var, не из файла на диске).
-2. `sudo apt-get update` (если event.update != false).
-3. `sudo DEBIAN_FRONTEND=noninteractive apt-get install -y <packages>`.
-4. Проверить `dpkg -l <package>` для каждого.
-5. Вернуть `{"status": "ok", "installed": [...], "already_installed": [...], "failed": [...]}`.
-
-**Обработка ошибок:**
- SSH connection refused → retry 3 раза с шагом 10 сек (ВМ может ещё грузиться).
- apt lock → retry 5 раз с шагом 15 сек.
- Частичный фейл (2 из 5 пакетов не найдены) → status="partial", failed=[...].
- Полный фейл → raise Exception с читаемым сообщением.
-
-**Идемпотентность:** Повторный запуск безопасен — apt-get install -y ничего не ломает.
-
-### 2. install-docker (Этап A)
-
-**Назначение:** Docker CE + docker-compose plugin по официальной инструкции.
-
-**handler.py** — entrypoint: `handler.install`
-
-```
-event_json:
-  compose: true          # опционально — ставить ли docker-compose plugin (default: true)
-
-env_vars:
-  VM_IP, SSH_USER, SSH_KEY  — те же
-
-requirements.txt:
-  paramiko
-```
-
-**Логика:**
-1. SSH → проверить `docker --version`. Если уже есть — вернуть `{"status": "already_installed", ...}`.
-2. Добавить Docker apt-репозиторий (GPG ключ + sources.list).
-3. `apt-get install docker-ce docker-ce-cli containerd.io`.
-4. Если compose=true → `apt-get install docker-compose-plugin`.
-5. `sudo usermod -aG docker $SSH_USER`.
-6. Проверить: `docker run hello-world`.
-7. Вернуть `{"status": "ok", "docker_version": "...", "compose": true/false}`.
-
-**Идемпотентность:** Проверяет наличие перед установкой.
-
-### 3. install-postgres (Этап B)
-
-**Назначение:** PostgreSQL сервер + создание БД и пользователя.
-
-**handler.py** — entrypoint: `handler.install`
-
-```
-event_json:
-  pg_version: "14"                # опционально (default: "14")
-  db_name: "myapp"                # обязательно — имя БД
-  db_user: "app_user"             # обязательно — имя пользователя
-  db_password: "secure_pass"      # обязательно — пароль
-  listen_addresses: "*"           # опционально (default: "localhost")
-  allow_remote: true              # опционально — добавлять ли в pg_hba.conf (default: false)
-
-env_vars:
-  VM_IP, SSH_USER, SSH_KEY  — те же
-
-requirements.txt:
-  paramiko
-```
-
-**Логика:**
-1. SSH → проверить `psql --version`. Если нет:
-   - `apt-get install postgresql postgresql-contrib postgresql-client`.
-2. `systemctl is-active postgresql` — убедиться что запущен.
-3. Создать пользователя: `sudo -u postgres psql -c "CREATE USER ... PASSWORD ..."` (IF NOT EXISTS).
-4. Создать БД: `sudo -u postgres psql -c "CREATE DATABASE ... OWNER ..."` (IF NOT EXISTS).
-5. Если allow_remote: настроить `listen_addresses` в postgresql.conf + запись в pg_hba.conf.
-6. `systemctl restart postgresql` (если конфиг менялся).
-7. Проверить подключение: `psql -h localhost -U <user> -d <db> -c "SELECT 1"`.
-8. Вернуть `{"status": "ok", "pg_version": "14.x", "db_name": "myapp", ...}`.
-
-**Идемпотентность:** IF NOT EXISTS для пользователя и БД. Config-записи — grep перед append.
-
---
-
-## Terraform: sless.tf (скелет)
-
-```hcl
-# 2026-03-29 — sless.tf: sless_job функции для установки ПО на ВМ.
-# Каждый job подключается по SSH и ставит ПО.
-
-provider "sless" {
-  endpoint = "https://sless.kube5s.ru"
-  token    = var.sless_token
-}
-
-# --- Общие локальные переменные ---
-locals {
-  vm_ip    = nubes_vc_vm_v3.vm.state_out_flat["externalConnect"]
-  ssh_user = "ubuntu"
-  ssh_key  = file("${path.module}/vm_key")
-
-  # Общий набор env_vars для SSH-подключения к ВМ
-  ssh_env = {
-    VM_IP    = local.vm_ip
-    SSH_USER = local.ssh_user
-    SSH_KEY  = local.ssh_key
-  }
-}
-
-# --- 1. Базовые пакеты ---
-resource "sless_job" "install_packages" {
-  count = var.install_packages ? 1 : 0
-
-  name       = "vm-install-packages"
-  runtime    = "python3.11"
-  entrypoint = "handler.install"
-  source_dir = "${path.module}/functions/install-packages"
-
-  env_vars   = local.ssh_env
-  event_json = jsonencode({
-    packages = var.base_packages
-  })
-
-  run_id           = var.install_run_id
-  wait_timeout_sec = 600
-
-  depends_on = [nubes_vc_vm_v3.vm]
-}
-
-# --- 2. Docker ---
-resource "sless_job" "install_docker" {
-  count = var.install_docker ? 1 : 0
-
-  name       = "vm-install-docker"
-  runtime    = "python3.11"
-  entrypoint = "handler.install"
-  source_dir = "${path.module}/functions/install-docker"
-
-  env_vars   = local.ssh_env
-  event_json = jsonencode({
-    compose = true
-  })
-
-  run_id           = var.install_run_id
-  wait_timeout_sec = 900
-
-  depends_on = [
-    nubes_vc_vm_v3.vm,
-    sless_job.install_packages   # пакеты первыми
-  ]
-}
-
-# --- 3. PostgreSQL ---
-resource "sless_job" "install_postgres" {
-  count = var.install_postgres ? 1 : 0
-
-  name       = "vm-install-postgres"
-  runtime    = "python3.11"
-  entrypoint = "handler.install"
-  source_dir = "${path.module}/functions/install-postgres"
-
-  env_vars   = local.ssh_env
-  event_json = jsonencode({
-    pg_version    = var.pg_version
-    db_name       = var.pg_db_name
-    db_user       = var.pg_db_user
-    db_password   = var.pg_db_password
-    allow_remote  = var.pg_allow_remote
-  })
-
-  run_id           = var.install_run_id
-  wait_timeout_sec = 900
-
-  depends_on = [
-    nubes_vc_vm_v3.vm,
-    sless_job.install_packages   # базовые пакеты первыми
-  ]
-}
-```
-
-## Terraform: variables.tf (скелет)
-
-```hcl
-# 2026-03-29 — variables.tf: все переменные для examples/VM.
-
-# --- Nubes (уже есть, перенести из main.tf) ---
-variable "api_token"      { type = string; sensitive = true }
-variable "vm_public_key"  { type = string; sensitive = true }
-
-# --- Sless ---
-variable "sless_token" {
-  type        = string
-  sensitive   = true
-  description = "JWT-токен для sless API"
-}
-
-# --- Флаги установки ---
-variable "install_packages" {
-  type    = bool
-  default = true
-  description = "Установить базовые apt-пакеты"
-}
-
-variable "install_docker" {
-  type    = bool
-  default = false
-  description = "Установить Docker CE"
-}
-
-variable "install_postgres" {
-  type    = bool
-  default = false
-  description = "Установить PostgreSQL"
-}
-
-# --- Параметры ---
-variable "base_packages" {
-  type    = list(string)
-  default = ["git", "curl", "htop", "jq", "unzip"]
-  description = "Список apt-пакетов для install-packages"
-}
-
-variable "install_run_id" {
-  type    = number
-  default = 1
-  description = "Увеличить для повторного запуска всех install-джобов"
-}
-
-# --- PostgreSQL ---
-variable "pg_version"      { type = string;  default = "14" }
-variable "pg_db_name"      { type = string;  default = "myapp" }
-variable "pg_db_user"      { type = string;  default = "app_user" }
-variable "pg_db_password"  { type = string;  sensitive = true; default = "" }
-variable "pg_allow_remote" { type = bool;    default = false }
-```
-
-## Terraform: outputs.tf (скелет)
-
-```hcl
-# 2026-03-29 — outputs.tf: статусы установки.
-
-output "install_packages_result" {
-  value = var.install_packages ? sless_job.install_packages[0].message : "skipped"
-}
-
-output "install_docker_result" {
-  value = var.install_docker ? sless_job.install_docker[0].message : "skipped"
-}
-
-output "install_postgres_result" {
-  value = var.install_postgres ? sless_job.install_postgres[0].message : "skipped"
-}
-```
-
---
-
-## Порядок выполнения для агента
-
-### Фаза 1: Инфраструктура Terraform (4 файла)
-
-1. Создать `variables.tf` — все переменные (перенести из main.tf + новые).
-2. Создать `sless.tf` — провайдер sless + 3 ресурса sless_job.
-3. Создать `outputs.tf` — статусы.
-4. Обновить `main.tf` — вынести переменные в variables.tf, добавить required_providers sless.
-
-> **Проверка:** `terraform validate` должен пройти.
-
-### Фаза 2: Функция install-packages (1 функция, полный E2E)
-
-1. Создать `functions/install-packages/handler.py`.
-2. Создать `functions/install-packages/requirements.txt` (paramiko).
-3. Добавить `sless_token` в `terraform.tfvars`.
-4. `terraform apply` с `install_packages = true`.
-5. Убедиться: `phase = Succeeded`, пакеты установлены на ВМ.
-
-> **Это ключевой момент.** Если install-packages прошёл E2E — паттерн работает, остальные функции аналогичны.
-
-### Фаза 3: Функции install-docker и install-postgres
-
-1. Создать `functions/install-docker/handler.py` + `requirements.txt`.
-2. Создать `functions/install-postgres/handler.py` + `requirements.txt`.
-3. `terraform apply` с `install_docker = true, install_postgres = true`.
-4. Проверить: Docker установлен, PostgreSQL работает, БД создана.
-
-### Фаза 4: Полировка и README
-
-1. Обновить `README.md` — как использовать шаблон с sless.
-2. `terraform apply` с нуля (destroy + apply) — весь цикл.
-
---
-
-## SSH через paramiko — референсный паттерн
-
-```python
-# Этот блок — основа для всех handler.py. Копировать и адаптировать.
-
-import os, io, time
-import paramiko
-
-def _ssh_connect(retries=3, delay=10):
-    """Подключение к ВМ по SSH. Retry при connection refused (ВМ грузится)."""
-    key = paramiko.Ed25519Key.from_private_key(io.StringIO(os.environ["SSH_KEY"]))
-    for attempt in range(retries):
-        try:
-            client = paramiko.SSHClient()
-            client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
-            client.connect(
-                hostname=os.environ["VM_IP"],
-                username=os.environ["SSH_USER"],
-                pkey=key,
-                timeout=15,
-            )
-            return client
-        except Exception as e:
-            if attempt == retries - 1:
-                raise RuntimeError(f"SSH connection failed after {retries} attempts: {e}")
-            time.sleep(delay)
-
-def _ssh_run(client, cmd, check=True):
-    """Выполнить команду. При check=True — бросить ошибку если exit_code != 0."""
-    stdin, stdout, stderr = client.exec_command(cmd, timeout=300)
-    exit_code = stdout.channel.recv_exit_status()
-    out = stdout.read().decode().strip()
-    err = stderr.read().decode().strip()
-    if check and exit_code != 0:
-        raise RuntimeError(f"Command failed (exit {exit_code}): {cmd}\nstderr: {err}")
-    return exit_code, out, err
-```
-
---
-
-## Ограничения и подводные камни
-
-1. **SSH через внешний IP** — Sless-поды находятся в k8s кластере `kube5s.ru`, VM — в Nubes vDC.
-   Эти сети **не связаны напрямую**. Используем `externalConnect` (публичный IP).
-   `internalConnect` (`10.x.x.x`) доступен только внутри Nubes vDC — из sless-подов он недостижим.
-
-   > **TODO для DevOps облака Nubes:** обсудить организацию внутреннего трафика между
-   > k8s кластером и Nubes vDC — VPN/peering/dedicated link. До решения — только внешний IP.
-   > Когда появится внутренний маршрут — заменить `externalConnect` → `internalConnect` в locals.
-
-   В `sless.tf`:
-   ```hcl
-   # TODO: заменить на internalConnect когда DevOps настроят сеть между кластером и vDC
-   vm_ip = nubes_vc_vm_v3.vm.state_out_flat["externalConnect"]
-   ```
-
-2. **SSH_KEY в env_var** — Содержимое приватного ключа передаётся как env var (строка).
-   paramiko умеет читать из `io.StringIO`. Не писать в файл.
-
-2. **apt lock** — Если apt уже заблокирован (unattended-upgrades), будет ошибка.
-   Retry с проверкой `/var/lib/dpkg/lock-frontend`.
-
-3. **depends_on обязателен** — ВМ должна быть готова до запуска job.
-   `depends_on = [nubes_vc_vm_v3.vm]`. Без этого terraform может запустить параллельно.
-
-4. **run_id для повторного запуска** — sless_job не перезапускается автоматически.
-   Чтобы перезапустить: `install_run_id = 2` → `terraform apply`.
-
-5. **wait_timeout_sec** — Kaniko-сборка + выполнение. 600с для мелких пакетов, 900с для Docker/PG.
-
-6. **Vault пока нет** — Секреты (pg_password, ssh_key) передаются через tfvars.
-   Архитектура готова к замене на Vault data source позже (env_vars заполняются из vault).
-
-7. **Drift не отслеживается** — Job-модель ≠ полноценный stateful resource.
-   Если кто-то удалит Docker на ВМ — Terraform не знает. Перезапуск: увеличить run_id.
@@ -4,431 +4,6 @@

 ---

-## 2026-04-01 — Nubes PostgreSQL API: ошибки при создании ресурсов (PG_TEST)
-
-Все ошибки воспроизводились в `examples/PG_TEST` при тестировании провайдера
-`terra.k8c.ru/nubes/nubes` v5.0.51. VM: `naeel@5.172.178.213`, PG-инстанс: `pg-test-02`.
-
---
-
-### ERR-PG-01: "Invalid JSON String" при создании инстанса с json_parameters
-
-**Симптом**
-
-```
-Error: Ошибка клиента
-  with nubes_postgres.pg_test_instance
-  Invalid JSON String
-```
-
-**Причина**
-
-При передаче параметра `json_parameters` (строка JSON с кастомными настройками PG)
-Nubes API v5 возвращает "Invalid JSON String" независимо от корректности самого JSON.
-Вероятно — баг в провайдере или несовместимость формата с deck-api-test.
-
-**Решение**
-
-Убран `json_parameters` из конфигурации `nubes_postgres`. PG запускается
-с дефолтными параметрами движка. При необходимости custom params — требует
-диагностики на стороне Nubes (`.api_endpoint = deck-api-test.ngcloud.ru`).
-
-**Файл:** [examples/PG_TEST/postgres.tf](examples/PG_TEST/postgres.tf)
-
---
-
-### ERR-PG-02: vault_secrets меняется вне Terraform → destroy+recreate всей цепочки
-
-**Симптом**
-
-Каждый `terraform apply` обнаруживает изменения "снаружи Terraform":
-
-```
-Note: Objects have changed outside of Terraform
-  # nubes_postgres.pg_test_instance has changed
-  ~ vault_secrets = (sensitive value)
-```
-
-Это вызывает план с `-/+ destroy and then create replacement` для `pg_test_user`
-и `pg_test_db`, хотя реально они не изменились.
-
-**Причина**
-
-Nubes API обновляет `vault_secrets` (путь к Vault с паролями пользователей)
-каждый раз при создании/удалении пользователей. Terraform видит это как
-"изменение снаружи" и считает `postgres_id` изменённым (т.к. он `(known after apply)`
-после обновления инстанса), что форсирует замену всех дочерних ресурсов.
-
-**Попытка решения**
-
-Добавить `lifecycle { ignore_changes = [vault_secrets] }` — **не работает**.
-Terraform выводит предупреждение:
-> "The attribute vault_secrets is decided by the provider alone and therefore
-> there can be no configured value to compare with. Including this attribute
-> in ignore_changes has no effect."
-
-`vault_secrets` — Computed-only (провайдер его полностью контролирует),
-`ignore_changes` для таких атрибутов игнорируется.
-
-**Реальная причина** destroy+recreate: при обнаружении `vault_secrets` как
-"изменённого снаружи" Terraform обновляет `nubes_postgres` in-place, но
-в плане ставит `id = (known after apply)` — это форсирует замену зависимых
-ресурсов у которых `postgres_id` ссылается на `nubes_postgres.*.id`.
-
-**Статус: открытая проблема.** Обходной путь — выполнять `apply` только на
-чистом state (без накопленных изменений снаружи). После первого полного
-`apply` с `lifecycle ignore_changes` убран как неэффективный.
-
-**Файл:** [examples/PG_TEST/postgres.tf](examples/PG_TEST/postgres.tf)
-
---
-
-### ERR-PG-03: Race condition при параллельном создании пользователей
-
-**Симптом**
-
-При одновременном создании двух и более `nubes_postgres_user` на одном инстансе:
-
-```
-Error: Ошибка клиента
-  with nubes_postgres_user.test_extra_user1
-  операция XXXX завершилась с ошибкой: Секрет для пользователя extra_user1 не был создан
-```
-
-Или:
-
-```
-  операция XXXX завершилась с ошибкой: key doesn't exist
-```
-
-**Причина**
-
-Nubes API не поддерживает параллельное создание пользователей на одном PG-инстансе.
-Внутри Nubes: каждое создание пользователя пишет в Vault, а Vault/Deck
-не справляются с конкурентными записями в один Secret.
-
-**Решение**
-
-Принудительная последовательная цепочка через `depends_on`:
-
-```
-pg_test_user → pg_test_db → extra_user1 → extra_user2 → extra_db1 → extra_db2
-```
-
-Каждый `nubes_postgres_user` и `nubes_postgres_database` явно ждёт предыдущий.
-`depends_on` нужен даже если прямой ссылки на атрибуты нет.
-
-**Файлы:** [examples/PG_TEST/postgres.tf](examples/PG_TEST/postgres.tf),
-[examples/PG_TEST/postgres_extra.tf](examples/PG_TEST/postgres_extra.tf)
-
---
-
-### ERR-PG-04: Роль app_user не работает для nubes_postgres_user
-
-**Симптом**
-
-```
-Error: Ошибка клиента
-  with nubes_postgres_user.test_app_user,
-  операция XXXX завершилась с ошибкой: Секрет для пользователя test_app_user не был создан
-```
-
-Ресурс висит ~3 минуты перед ошибкой. Воспроизводится стабильно.
-
-**Причина**
-
-Роль `app_user` не поддерживается для создания PostgreSQL пользователей
-через `nubes_postgres_user` в данной версии провайдера/API. Возможно, роль
-предусмотрена только для другого механизма доступа.
-
-**Решение**
-
-Использовать только роль `ddl_user` для ресурса `nubes_postgres_user`.
-Создание пользователей с `app_user` — не работает на `deck-api-test.ngcloud.ru`.
-
-Из конфигурации удалён ресурс `nubes_postgres_user.test_app_user`.
-
---
-
-### ERR-PG-05: "Нарушена консистентность" — пользователь есть в API, нет в state_out
-
-**Симптом**
-
-```
-Error: Нарушена консистентность
-  with nubes_postgres_user.test_extra_user1
-  Операция вернула duplicate/exist, но объект не найден в state_out
-```
-
-**Причина**
-
-Пользователь `extra_user1` был создан Nubes API на предыдущей (упавшей) попытке apply.
-Terraform state не зафиксировал успех (т.к. apply завершился ошибкой), но Nubes
-счётной записью `extra_user1` не удалил.
-
-Флаг `adopt_existing_on_create = true` должен был решить это, но он проверяет
-`state_out` инстанса — а там пользователь не отражается (из-за ERR-PG-02:
-`vault_secrets` изменялся и инстанс был в "changed outside" состоянии).
-
-**Решение**
-
-Полный `terraform destroy` для очистки state + ресурсов в API, затем
-`terraform apply` с уже включённым `lifecycle { ignore_changes = [vault_secrets] }`.
-После этого проблема не воспроизводится.
-
---
-
-### ERR-PG-06: Второй пользователь на инстансе не может получить vault_secrets
-
-**Симптом**
-
-При создании второго пользователя на PG-инстансе (первый уже существует):
-
-```
-Error: Ошибка клиента
-  with nubes_postgres_user.test_extra_user1
-  операция 4D816F17-F43E-4062-AE37-5098ADE07041 завершилась с ошибкой:
-  Секрет для пользователя test_eu1 не был создан
-```
-
-Ресурс висит ~3–4 минуты, затем падает с этой ошибкой. Воспроизводится стабильно
-для любого второго пользователя (проверено на `extra_user1`, `test_eu1`)
-независимо от роли (`ddl_user`), имени и порядка depends_on.
-
-**Важно**: `pg_test_user` (первый пользователь, созданный при инициализации
-инстанса) всегда успешно проходит через adoption за 1 секунду — его vault_secret
-уже был создан при первом apply. Только создание **нового** второго пользователя
-всегда приводит к этой ошибке.
-
-**Причина**
-
-Vault backend для PG-инстанса `e0e74801` (тест-окружение `k8s-3-sandbox-nubes-ru`)
-вероятно ограничен одной vault-записью на инстанс. При попытке создать vault_secrets
-для второго пользователя — запись не создаётся, провайдер возвращает ошибку через
-~3–4 минуты ожидания.
-
-Либо vault policy для данного инстанса предусмотрена только для основного
-пользователя (`user0`). Дополнительные пользователи не имеют прав vault-path.
-
-**Статус: открытая проблема, требует диагностики на стороне Nubes.**
-
-**Следствие для архитектуры**:
-В текущем тест-окружении Nubes PostgreSQL поддерживает **только одного пользователя
-с vault_secrets** на инстанс. Lifecycle-тесты с несколькими пользователями
-(**goal** текущей сессии) — **невозможны** без исправления vault-конфигурации.
-
-**Файл:** [examples/PG_TEST/postgres_extra.tf](examples/PG_TEST/postgres_extra.tf)
-
---
-
-### ERR-PG-07: HTTP 408 от IAM API (auth-api-test.ngcloud.ru)
-
-**Симптом**
-
-```
-Error: Ошибка клиента
-  with nubes_postgres_user.pg_test_user
-  ошибка API 408: {"IAM URL":"https://auth-api-test.ngcloud.ru/api/v1/auth/user",
-  "idpResponse":{"prefix":{"status_text":"Request Time-out","statuscode":"408 Request Time-out"}}}
-```
-
-Может проявляться даже на этапе `terraform plan` (refresh инстанса).
-
-**Причина**
-
-Транзитная перегрузка тест-IAM-сервиса `auth-api-test.ngcloud.ru`. Возникает
-после серии интенсивных apply/destroy в течение одного или нескольких часов.
-
-**Решение**
-
-Подождать 5–10 минут и повторить apply. Ошибка проходит самостоятельно.
-
-**Важно**: в production окружении (`auth-api.ngcloud.ru`) эта проблема
-предположительно не воспроизводится.
-
---
-
-## 2026-04-03 — Коррекции и новые находки (PostgreSQL续)
-
-### ERR-PG-02: id=(known after apply) при Update — ИСПРАВЛЕНО ✅
-
-**Статус обновления**: Проблема уже решена в текущей версии провайдера.
-
-**Где было**: `internal/provider/postgres_resource.go` Update() метод устанавливал `id = (known after apply)`
-
-**Как исправлено**: Строка ~845 добавлена явная сохранение ID:
-```go
-// fix: plan.ID is Computed (empty in plan), must preserve existing ID from state
-plan.ID = state.ID
-```
-
-**Проверка**: `terraform plan` больше НЕ показывает destroy+recreate зависимых ресурсов.  
-**Результат плана (ответно)**: `Plan: 0 to add, 1 to change, 0 to destroy` (только update, без replace)
-
-**Вывод**: ERR-PG-02 не актуален для текущей версии провайдера.
-
---
-
-### ERR-PG-06: Второй пользователь — ПЕРЕКВАЛИФИЦИРОВАНО 🔄
-
-**Изменение статуса**: ERR-PG-06 была НЕВЕРНО диагностирована.
-
-**Что было думано**: "Vault backend ограничен одним пользователем на инстанс"
-
-**Что обнаружено**: `pg_test_user3` (u3) успешно создан в terraform state! Это второй пользователь на инстансе `pg-test-02`.
-
-**Проверки**:
-```bash
-terraform state list
-# Output:
-# nubes_postgres.pg_test_instance
-# nubes_postgres_user.pg_test_user         ← user0
-# nubes_postgres_user.pg_test_user3        ← u3 (УСПЕШНО)
-```
-
-**Статус**: Многопользовательское создание **РАБОТАЕТ** при правильной последовательности `depends_on`.
-
-**Реальная проблема**: Не в создании пользователей, а в том что файл `postgres_extra.tf` с третьим пользователем был переименован в `postgres_extra.tf11` (бэкап), и текущий конфиг не имел этого файла.
-
-**Вывод**: ERR-PG-06 была следствием неполного тестирования, а не действительным ограничением API.
-
---
-
-### ERR-PG-08: Concurrent Operations Are Not Supported ❌ НОВАЯ ПРОБЛЕМА
-
-**Симптом**
-
-После успешного завершения Update операции на `nubes_postgres`, попытка создать
-зависимый ресурс (например БД) немедленно падает с ошибкой 422:
-
-```
-Error: Ошибка клиента
-  with nubes_postgres_database.pg_test_db
-  ошибка API 422: {
-    "DETAIL": "There is a started operation on this instance",
-    "TYPE": "about:blank",
-    "TITLE": "Concurrent operations are not supported (job status: SUCCESS)"
-  }
-```
-
-**Когда воспроизводится**
-1. `terraform plan` обнаруживает изменения (например, `vault_secrets` drift)
-2. Apply запускает Update инстанса: `nubes_postgres.pg_test_instance: Modifying...`
-3. Update успешно завершается: `Modifications complete after 0s`
-4. Terraform пытается создать DB: `nubes_postgres_database.pg_test_db: Creating...`
-5. **FAIL**: 422 Concurrent operations
-
-**Попытки обхода (неуспешные)**
- Добавлен `depends_on = [pg_test_user3]` — не помогло ✗
- Ожидание 60 секунд между apply'ами — не помогло ✗
- Ожидание 120 секунд — не помогло ✗
-
-**Причина**
-
-Nubes API имеет встроенный serial-lock на операции per-instance. Даже хотя
-`WaitForOperation()` возвращает `IsSuccessful = true`, сервер всё ещё обрабатывает
-асинхронные побочные эффекты (Vault sync, state reconciliation и тд). Новые запросы
-на операции отклоняются с 422 до полного завершения.
-
-**Текущий workaround**
-
-Разбить apply на несколько фаз вручную:
-```bash
-# Фаза 1: создание инстанса + пользователей (без БД)
-cp postgres.tf postgres.tf.bak
-sed -i '/resource.*nubes_postgres_database/,/^}/d' postgres.tf
-terraform apply -auto-approve
-
-# Фаза 2: добавить БД обратно и применить
-cp postgres.tf.bak postgres.tf
-terraform apply -auto-approve
-```
-
-**Статус**: Открытая проблема в провайдере. Требует fix на уровне `WaitForOperation()`.
-
-**Рекомендуемое решение**: Добавить post-completion delay (30–60 сек) или retry mechanism
-в `internal/provider/client_impl.go` метод `WaitForOperation`.
-
-**Файл для анализа**: [`internal/provider/client_impl.go` line 240+](../../terra/terraform/internal/provider/client_impl.go#L240)
-
-**Документация**: [ERR-PG-08-concurrent-operations.md](ERR-PG-08-concurrent-operations.md)
-
---
-
-## 2026-03-29 — SSH timeout после destroy VM example
-
-### Симптом
-
-После `terraform destroy` для [examples/VM](examples/VM) попытка зайти по SSH на target VM завершилась таймаутом:
-
- `ssh: connect to host 185.247.187.154 port 22: Connection timed out`
-
-### Причина
-
-Это ожидаемое поведение для сценария suspend: VM перестаёт отвечать по SSH после destroy, а затем поднимается обратно на `terraform apply`.
-
-### Что сделали
-
- Подтвердили, что `terraform apply` после destroy восстанавливает доступ и повторно запускает install jobs.
-
---
-
-## 2026-03-26 — БАГ ГЕНЕРАТОРА: modify-only поля помечаются Required в schema ресурса
-
-```
-Error: Missing required argument
-  on vc_org.tf line 5, in resource "nubes_vc_org" "dev_org":
-   5: resource "nubes_vc_org" "dev_org" {
-The argument "v_i_p_configure" is required, but no definition was found.
-The argument "resource_name" is required, but no definition was found.
-```
-
-### Причина
-
-Генератор (`~/terra/terraform/devops/`) при создании Go-кода ресурса (`19_vc_org_resource.go`)
-помечает **все операции ресурса** как `Required` в схеме, включая поля,
-которые нужны только для операции `modify` (не для `create`).
-
-Конкретный пример: `vIPConfigure` (код параметра 662) — это поле операции `modify`,
-но попадает в schema с `Required: true`:
-
-```go
-"v_i_p_configure": schema.StringAttribute{Required: true},
-```
-
-В YAML-описании сервиса (19_vc_org.yaml) `vIPConfigure` объявлен только под
-`operations.modify.params`, а не под `operations.create.params`.
-
-### Что нужно исправить в генераторе
-
-В `~/terra/terraform/devops/` (файлы `02_generate_resources_and_docs*.go/sh`):
-
-Поля, принадлежащие только операции `modify` (или другим не-create операциям),
-должны генерироваться как **`Optional: true, Computed: true`**, а не `Required: true`.
-
-Логика:
- поле в `operations[create].params` → `Required: true`
- поле только в `operations[modify].params` → `Optional: true, Computed: true`
- поле только в state (read-only) → `Computed: true`
-
-### Временный workaround (действующий)
-
-В `terraform.tf`-манифесте указывать пустую строку:
-
-```hcl
-v_i_p_configure = ""   # modify-only поле; при create не отправляется в API
-```
-
-Провайдер при Create не передаёт это поле в API (строка 418/556 params),
-но schema.Required требует non-null значение в плане.
-
-### Файлы для правки
-
- `~/terra/terraform/devops/profiles/test/generated/go/19_vc_org_resource.go` — сгенерированный, не менять вручную
- **Править нужно шаблоны/генераторы** в `~/terra/terraform/devops/`
-
---
-
 ## 2026-03-22 — БАГ: CreateService/CreateFunction возвращает 409 при `terraform apply -replace` (ИСПРАВЛЕН)

 ### Симптом
@@ -1618,54 +1193,3 @@ if errors.IsInvalid(err) {
 **Симптом:** После `kubectl delete pod` оператора API возвращает 503 (не 400/404/409)  
 **Причина:** Operator pod = API server. Пока старый pod завершается и новый не поднялся — ingress/proxy отдаёт 503  
 **Исправление:** Тест принимает 503/502 как валидный транзиентный ответ с NOTE
-
---
-
-## 2026-04-08/09 — SQS Operator UI (v0.1.7–v0.1.12)
-
-### ERR-SQS-01: UI зависает на загрузке (shimmer)
-
-**Симптом:** https://sqs.kube5s.ru/sqs-ui/test001/ — страница грузится (HTTP 200), но список очередей не появляется, крутится shimmer.
-**Причина:** После стресс-теста с `autoCreateQueues=true` ElasticMQ накопил 4912 очередей `no-such-queue-*`. UI грузил все → зависал.
-**Решение:** Удалить H2 базу (`rm /data/elasticmq.mv.db`) + kubectl rollout restart.
-**Профилактика:** В стресс-тесте error-injection паттерн создаёт запросы к несуществующим очередям — при `autoCreateQueues=true` они все создаются. Чистить базу после стресс-теста.
-
---
-
-### ERR-SQS-02: 503 после kubectl rollout restart (self-healing)
-
-**Симптом:** После SH02/SH05 (удаление Service) UI возвращает 503.
-**Причина:** `ensureService` создавал сервис только с портом 9324. При пересоздании порт 3000 (UI) не добавлялся.
-**Решение (v0.1.11):** `ensureService` проверяет `qs.Spec.EnableUI` и добавляет порт 3000 при необходимости.
-
---
-
-### ERR-SQS-03: SendMessage зависает после rollout restart
-
-**Симптом:** HTTP-запрос `SendMessage` не возвращается, висит.
-**Причина:** При `kubectl rollout restart` JVM убивается принудительно. H2 database lock (`elasticmq.mv.db`) не снимается. При следующем старте ElasticMQ actor застревает на восстановлении.
-**Решение (v0.1.10):** Добавить `FILE_LOCK=NO` в JDBC URL в HOCON конфиге. H2 игнорирует stale lock.
-
---
-
-### ERR-SQS-04: queueservice_controller.go обнулён (0 байт)
-
-**Симптом:** `wc -l queueservice_controller.go` → 0. Go build падает с "no Go files".
-**Причина:** Диск был 100% заполнен (54GB docker images). sshfs при записи через VS Code cursor создал пустой файл вместо ошибки.
-**Решение:** `git checkout HEAD -- internal/controller/queueservice_controller.go` + повторное применение патчей v0.1.11.
-**Профилактика:** `docker system prune -af` регулярно. Проверять `df -h` перед крупными операциями.
-
---
-
-### ERR-SQS-05: 404 на /queues/xxx при навигации в UI
-
-**Симптом:** Клик на очередь в UI → браузер переходит на `/queues/1234` → nginx 404.
-**Причина:** Next.js в образе `elasticmq-ui` собран с `basePath=""`. Внутренние переходы идут по абсолютным путям без prefix `/sqs-ui/tenantID/`. Ingress не знал о маршруте `/queues`.
-**Решение (v0.1.12):** `ensureIngressUIQueues` — третий ingress `/queues` PathTypePrefix → UI service:3000. Без rewrite-target.
-
-### ERR-SQS-06: H2 file lock при rollout restart (повторяющийся)
-
-**Симптом:** После `kubectl rollout restart` ElasticMQ стартует, SQS API отвечает, но SendMessage зависает навсегда. В логах: `MVStoreException: The file is locked: /data/elasticmq.mv.db`.
-**Ложный фикс (v0.1.10):** `FILE_LOCK=NO` в JDBC URI — не помогает, т.к. lock на уровне `FileChannel.lock()`, не JDBC.
-**Настоящая причина:** `Deployment strategy: RollingUpdate` + `PVC: ReadWriteOnce`. При rollout новый pod поднимается ДО убийства старого. Оба монтируют один PVC, ElasticMQ-1 держит lock → ElasticMQ-2 не может открыть H2 → persistence actor падает → write-операции зависают (dead letters).
-**Решение (v0.1.13):** Strategy `Recreate` (старый pod убивается до создания нового), `preStop: sleep 3` (graceful H2 shutdown), `livenessProbe timeoutSeconds: 3` (защита от GC pause false positive).
@@ -1,193 +0,0 @@
-# PG_TEST — инфраструктура тестирования Nubes PostgreSQL
-
-Создан: 2026-04-01
-
---
-
-## Цель
-
-Набор Terraform-манифестов для тестирования провайдера `nubes` (ресурсы PostgreSQL).
-Покрывает: создание инстанса, управление пользователями и базами данных, lifecycle-операции.
-
-Также используется как шаблон для передачи заказчикам — достаточно вписать
-`api_token`, `s3_uid`, `realm` в `terraform.tfvars`.
-
---
-
-## Расположение
-
-| Место | Путь |
-|---|---|
-| Локально | `/home/naeel/remote_dev/sless/examples/PG_TEST/` |
-| На VM | `/home/naeel/terra/sless/examples/PG_TEST/` |
-| VM | `naeel@5.172.178.213` |
-| SSH-ключ | `secrets/naeel_vm_id_ed25519` |
-
-> **Правило:** все `terraform` команды выполняются только на VM через SSH.
-> Локально — только редактирование файлов + `scp` для синхронизации.
-
---
-
-## Файловая структура
-
-```
-examples/PG_TEST/
-├── main.tf                   # провайдер nubes + переменные
-├── postgres.tf               # инстанс + базовый пользователь + база
-├── postgres_extra.tf         # доп. пользователи и базы для lifecycle-тестов
-├── outputs.tf                # host, port, user, password, DSN
-├── terraform.tfvars          # рабочие значения (не в git, токен и IDs)
-├── terraform.tfvars.example  # шаблон для заказчика (masked placeholders)
-└── test_lifecycle.sh         # скрипт последовательного lifecycle-тестирования
-```
-
---
-
-## Провайдер
-
-```hcl
-terraform {
-  required_providers {
-    nubes = {
-      source  = "terra.k8c.ru/nubes/nubes"
-      version = "5.0.51"
-    }
-  }
-}
-
-provider "nubes" {
-  api_endpoint = "https://deck-api-test.ngcloud.ru/api/v1/index.cfm"
-  api_token    = var.api_token
-}
-```
-
---
-
-## Ресурсы
-
-### nubes_postgres (pg_test_instance)
-
- `resource_name = "pg-test-02"`
- `resource_realm = "k8s-3-sandbox-nubes-ru"`
- `app_version = "17"` (PostgreSQL 17)
- CPU: 500m, Memory: 512 MiB, Disk: 1 GiB
- `adopt_existing_on_create = true`
- `operation_timeout = "11m"`
- **`lifecycle { ignore_changes }`** — не решает проблему с `vault_secrets` (см. ERR-PG-02)
-
-Инстанс ID: `e0e74801-d68e-4637-8ef3-d846b289846e`
-
-### nubes_postgres_user
-
- Рабочая роль: **только `ddl_user`** (роль `app_user` не работает — ERR-PG-04)
- `adopt_existing_on_create = true`
- Пользователи создаются **строго последовательно** через `depends_on` (ERR-PG-03)
-
-### nubes_postgres_database
-
- `adopt_existing_on_create = true`
- `db_owner` = username из `nubes_postgres_user`
- Создаётся после всех пользователей которые будут db_owner (через `depends_on`)
-
---
-
-## Обязательная цепочка depends_on
-
-Nubes API не поддерживает параллельные операции на одном PG инстансе.
-Нарушение вызывает race condition в Vault (ERR-PG-03).
-
-```
-nubes_postgres
-  └─→ pg_test_user (ddl_user)
-        └─→ pg_test_db  (owner=pg_test_user)
-              └─→ test_extra_user1 (ddl_user)
-                    └─→ test_extra_user2 (ddl_user)
-                          └─→ test_extra_db1 (owner=extra_user1)
-                                └─→ test_extra_db2 (owner=extra_user2)
-```
-
---
-
-## Переменные (terraform.tfvars)
-
-| Переменная | Описание | Пример |
-|---|---|---|
-| `api_token` | JWT токен Nubes API | `eyJ...` |
-| `s3_uid` | UUID S3 bucket для бэкапов PG | `332cdb0d-...` |
-| `realm` | realm кластера | `k8s-3-sandbox-nubes-ru` |
-| `pg_resource_name` | имя PG инстанса | `pg-test-02` |
-| `pg_username` | имя основного пользователя | `user0` |
-| `pg_db_name` | имя основной базы данных | `db0` |
-| `pg_role` | роль основного пользователя | `ddl_user` |
-
---
-
-## Команды
-
-Все команды — через SSH на VM:
-
-```bash
-SSH="ssh -i /home/naeel/remote_dev/sless/secrets/naeel_vm_id_ed25519 -o StrictHostKeyChecking=no naeel@5.172.178.213"
-TF="cd /home/naeel/terra/sless/examples/PG_TEST &&"
-
-# Применить конфигурацию
-$SSH "$TF terraform apply -auto-approve"
-
-# Проверить state
-$SSH "$TF terraform state list"
-
-# Посмотреть outputs
-$SSH "$TF terraform output"
-
-# Удалить все ресурсы
-$SSH "$TF terraform destroy -auto-approve"
-```
-
-Синхронизация файлов на VM:
-
-```bash
-scp -i secrets/naeel_vm_id_ed25519 examples/PG_TEST/postgres.tf \
-    naeel@5.172.178.213:/home/naeel/terra/sless/examples/PG_TEST/postgres.tf
-```
-
---
-
-## Известные ограничения API
-
-| # | Проблема | Статус |
-|---|---|---|
-| ERR-PG-01 | `json_parameters` — "Invalid JSON String" | обойдено: убран параметр |
-| ERR-PG-02 | `vault_secrets` обновляется вне TF | открытая проблема: `ignore_changes` не эффективен |
-| ERR-PG-03 | Race condition при параллельном создании users | обойдено: `depends_on` chain |
-| ERR-PG-04 | Роль `app_user` — "Секрет не был создан" | не работает, используем только `ddl_user` |
-| ERR-PG-05 | "Нарушена консистентность" при stale state | решение: `terraform destroy` + rebuild |
-
-Подробности: [doc/errors/log.md](doc/errors/log.md)
-
---
-
-## Ожидаемые времена операций
-
-| Операция | Примерное время |
-|---|---|
-| Создание `nubes_postgres_user` | ~50–75 секунд |
-| Удаление `nubes_postgres_user` | ~56–76 секунд |
-| Создание `nubes_postgres_database` | ~47–70 секунд |
-| Удаление `nubes_postgres_database` | ~46–92 секунды |
-| Обновление `nubes_postgres` in-place | мгновенно (~0s) |
-
-Полный `apply` с 6 новыми ресурсами занимает **~8–12 минут**.
-
---
-
-## Lifecycle-тест (test_lifecycle.sh)
-
-Скрипт тестирует последовательность операций:
-
-1. **Создать всё** — apply базовой конфигурации + extra
-2. **Удалить user2 + db2** — закомментировать ресурсы, apply
-3. **Воссоздать** — раскомментировать, apply
-4. **Сменить db_owner** — extra_db1.owner: extra_user1 → extra_user2
-5. **Невалидные параметры** — db_owner = несуществующий пользователь (ожидать ошибку API)
-
-Запуск: `$SSH "cd /home/naeel/terra/sless/examples/PG_TEST && bash test_lifecycle.sh"`
@@ -1,306 +0,0 @@
-# IoT MVP — Инженерная документация деплоя
-
-> Создано: 2026-04-04  
-> Ветка: Ioter  
-> Автор: GitHub Copilot (Claude Sonnet 4.6)
-
---
-
-## Архитектура IoT стека
-
-```
-IoT Device (физическое)
-    │ MQTT CONNECT (username="{ns}_{deviceId}", password=hex)
-    ▼
-EMQX 5.5.1 (sless/emqx)
-    │ HTTP POST /internal/mqtt/auth → sless-operator:9090
-    │ (auth backend: проверяет Secret iot-{deviceId} в k8s)
-    ▼
-    │ MQTT PUBLISH → topic: "{ns}/telemetry/{deviceId}"
-    ▼
-iot-mqtt-bridge (sless/iot-mqtt-bridge)
-    │ paho.mqtt.golang, подписка на "+/telemetry/+"
-    │ parse topic → namespace из первого сегмента
-    ▼
-RabbitMQ (sless/rabbitmq)
-    │ queue: "iot.{namespace}.telemetry"
-    ▼
-event-dispatcher (sless/event-dispatcher)
-    │ Trigger type=event, queue=iot.{namespace}.telemetry
-    ▼
-Serverless Function (пользовательский handler)
-```
-
---
-
-## Компоненты
-
-### 1. CRD IoTDevice
-
-**Расположение:** `iot/api/v1alpha1/device_types.go`  
-**API group:** `iot.kube5s.ru/v1alpha1`  
-**Манифест:** `iot/config/crd/bases/iot.kube5s.ru_iotdevices.yaml`
-
-Поля Spec:
-| Поле | Тип | Обязательное | Описание |
-|------|-----|--------------|----------|
-| `deviceId` | string | да | Идентификатор устройства. Pattern: `^[a-z0-9][a-z0-9-]*[a-z0-9]$` |
-| `enabled` | bool | нет | Активно ли устройство (default: true) |
-| `metadata` | map[string]string | нет | Произвольные метаданные (модель, локация) |
-
-Поля Status:
-| Поле | Описание |
-|------|----------|
-| `phase` | `Active` / `Disabled` / `Pending` / `Error` |
-| `mqttUsername` | `{namespace}_{deviceId}` |
-| `secretName` | Имя k8s Secret с credentials |
-| `topicPrefix` | `{namespace}/` |
-| `message` | Сообщение об ошибке если phase=Error |
-
-### 2. IoT Controller
-
-**Файл:** `iot/controllers/iotdevice_controller.go`  
-**Логика Reconcile:**
-
-```
-IoTDevice CREATE/UPDATE
-  1. Добавить finalizer "iot.kube5s.ru/device-cleanup"
-  2. Если Secret iot-{deviceId} не существует:
-     - Сгенерировать пароль: crypto/rand 32 bytes → hex (64 символа)
-     - OwnerReference → Secret удаляется каскадно при удалении IoTDevice
-     - Secret keys: mqtt-username, mqtt-password, device-id
-  3. Обновить Status: phase=Active, mqttUsername, secretName, topicPrefix
-  4. Если enabled=false → phase=Disabled
-
-IoTDevice DELETE
-  1. Проверить finalizer
-  2. Secret удаляется каскадно (OwnerReference)
-  3. Убрать finalizer → k8s завершает удаление
-```
-
-### 3. IoT REST API
-
-**Файл:** `internal/api/handler/iot_device_handler.go`
-
-| Endpoint | Auth | Описание |
-|----------|------|----------|
-| `POST /internal/mqtt/auth` | Нет (internal) | MQTT auth backend для EMQX |
-| `POST /v1/namespaces/{ns}/iot/devices` | JWT | Создать IoTDevice |
-| `GET /v1/namespaces/{ns}/iot/devices` | JWT | Список (без паролей) |
-| `GET /v1/namespaces/{ns}/iot/devices/{name}` | JWT | Получить (включая mqtt_password из Secret) |
-| `DELETE /v1/namespaces/{ns}/iot/devices/{name}` | JWT | Удалить |
-| `PATCH /v1/namespaces/{ns}/iot/devices/{name}` | JWT | Обновить enabled |
-
-**MQTT Auth endpoint:**
- Всегда HTTP 200 (EMQX игнорирует non-200)
- Парсит `username` → `{namespace}_{deviceId}` (разделитель первый `_`)
- Ищет k8s Secret `iot-{deviceId}` в namespace
- `crypto/subtle.ConstantTimeCompare` для защиты от timing attack
-
-### 4. EMQX 5.5.1
-
-**Манифест:** `deployments/k8s/emqx.yaml`  
-**Конфиг:** HOCON `emqx.conf`, монтируется как ConfigMap volume
-
-**Критически важные поля (без них EMQX 5.x не стартует):**
-```hocon
-node {
-  name = "emqx@127.0.0.1"   # Обязательно для single-node
-  cookie = "..."             # Erlang cluster cookie (любая строка для single-node)
-  data_dir = "/opt/emqx/data" # Директория данных Mnesia
-}
-```
-
-> ⚠️ EMQX 5.x: поля `node.cookie` и `node.data_dir` — **обязательные** (mandatory),
-> в отличие от 4.x где были значения по умолчанию.
-> При обновлении ConfigMap нужен `kubectl rollout restart` — Deployment не перезапускается автоматически.
-
-**Auth backend:**
-```hocon
-authentication = [{
-  mechanism = password_based
-  backend = http
-  method = post
-  url = "http://sless-operator.sless.svc:9090/internal/mqtt/auth"
-}]
-```
-
-### 5. iot-mqtt-bridge
-
-**Код:** `iot/cmd/mqtt-bridge/main.go`  
-**Манифест:** `deployments/k8s/iot-mqtt-bridge.yaml`  
-**Образ:** тот же что и оператор (`sless-operator:v0.1.50`), бинарь `/iot-mqtt-bridge`
-
-**Логика:**
-1. Подключиться к EMQX как MQTT клиент (credentials из Secret `iot-bridge-credentials`)
-2. Подписаться на `+/telemetry/+` (все namespace, все устройства)
-3. При получении: извлечь namespace из topic[0], publish в RabbitMQ `iot.{namespace}.telemetry`
-4. Reconnect loop при обрыве соединения
-
-**Envelope в RabbitMQ:**
-```json
-{
-  "namespace": "sless-user123",
-  "device_id": "sensor-01",
-  "topic": "sless-user123/telemetry/sensor-01",
-  "payload": "<base64 of raw MQTT payload>",
-  "received_at": "2026-04-04T07:19:30Z"
-}
-```
-
-### 6. Terraform Provider
-
-**Файл:** `terraform/provider/internal/resources/iot_device_resource.go`  
-**Ресурс:** `sless_iot_device`  
-**Версия провайдера:** `0.1.2`
-
-```hcl
-resource "sless_iot_device" "temperature_sensor" {
-  name      = "temp-sensor-01"
-  device_id = "temp-sensor-01"
-  enabled   = true
-  metadata = {
-    model    = "DHT22"
-    location = "Warehouse A"
-  }
-}
-
-output "mqtt_password" {
-  value     = sless_iot_device.temperature_sensor.mqtt_password
-  sensitive = true
-}
-```
-
---
-
-## Процедура первого деплоя
-
-### Предварительные условия
- Кластер с namespace `sless`
- sless-operator запущен (или будет запущен в шаге 3)
- RabbitMQ доступен в кластере
-
-### Шаги
-
-**1. Применить CRD (один раз, cluster-wide)**
-```bash
-kubectl apply -f iot/config/crd/bases/iot.kube5s.ru_iotdevices.yaml
-```
-
-**2. Обновить RBAC (добавить права на iot.kube5s.ru)**
-```bash
-kubectl apply -f deployments/k8s/rbac.yaml
-```
-
-**3. Применить EMQX**
-```bash
-kubectl apply -f deployments/k8s/emqx.yaml
-kubectl rollout status deployment/emqx -n sless
-```
-
-**4. Применить оператор (с IoT поддержкой)**
-```bash
-kubectl apply -f deployments/k8s/operator.yaml
-kubectl rollout status deployment/sless-operator -n sless
-```
-
-**5. Bootstrap credentials для mqtt-bridge**
-
-Создать системное IoTDevice устройство для bridge:
-```bash
-TOKEN=$(kubectl get secret sless-operator-secret -n sless \
-  -o jsonpath="{.data.SLESS_API_TOKEN}" | base64 -d)
-
-# Создать IoTDevice
-curl -X POST https://sless.kube5s.ru/v1/namespaces/sless/iot/devices \
-  -H "Authorization: Bearer $TOKEN" \
-  -H "Content-Type: application/json" \
-  -d '{"name":"iot-bridge","device_id":"iot-bridge","enabled":true}'
-
-# Подождать 5с пока контроллер создаст Secret
-sleep 5
-
-# Получить credentials
-CREDS=$(curl -s https://sless.kube5s.ru/v1/namespaces/sless/iot/devices/iot-bridge \
-  -H "Authorization: Bearer $TOKEN")
-MQTT_USER=$(echo $CREDS | jq -r .mqtt_username)
-MQTT_PASS=$(echo $CREDS | jq -r .mqtt_password)
-
-# Создать Secret для bridge Deployment
-kubectl create secret generic iot-bridge-credentials -n sless \
-  --from-literal=MQTT_USERNAME="$MQTT_USER" \
-  --from-literal=MQTT_PASSWORD="$MQTT_PASS"
-```
-
-**6. Применить mqtt-bridge**
-```bash
-kubectl apply -f deployments/k8s/iot-mqtt-bridge.yaml
-kubectl rollout status deployment/iot-mqtt-bridge -n sless
-```
-
-### Ожидаемый результат
-```
-emqx-xxx              1/1 Running
-iot-mqtt-bridge-xxx   1/1 Running
-sless-operator-xxx    1/1 Running
-```
-
---
-
-## Известные ошибки и решения
-
-### EMQX CrashLoopBackOff: required_field node.cookie/node.data_dir
-
-**Симптом:** `escript: exception throw: {emqx_conf_schema, [{kind=>validation_error, path=>"node.cookie", reason=>required_field}]}`
-
-**Причина:** EMQX 5.x требует явного задания `node { cookie, data_dir }` в конфиге.
-
-**Решение:** Добавить в `emqx.conf`:
-```hocon
-node {
-  name = "emqx@127.0.0.1"
-  cookie = "your-cookie-string"
-  data_dir = "/opt/emqx/data"
-}
-```
-После `kubectl apply` — сделать `kubectl rollout restart deployment/emqx -n sless`.
-
---
-
-### RBAC forbidden: iotdevices.iot.kube5s.ru
-
-**Симптом:** `{"error":"iotdevices.iot.kube5s.ru is forbidden: User \"system:serviceaccount:sless:sless-operator\" cannot create resource"}`
-
-**Причина:** ClusterRole `sless-operator` не включает API group `iot.kube5s.ru`.
-
-**Решение:** Добавить в `deployments/k8s/rbac.yaml` и применить:
-```yaml
- apiGroups: ["iot.kube5s.ru"]
-  resources: ["iotdevices"]
-  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["iot.kube5s.ru"]
-  resources: ["iotdevices/status"]
-  verbs: ["get", "update", "patch"]
- apiGroups: ["iot.kube5s.ru"]
-  resources: ["iotdevices/finalizers"]
-  verbs: ["update"]
-```
-
---
-
-### mqtt-bridge: multiple restarts при старте
-
-**Симптом:** `iot-mqtt-bridge RESTARTS=3`
-
-**Причина:** bridge пытается подключиться к EMQX который ещё не готов. Нормальное поведение.
-
-**Решение:** Bridge имеет reconnect loop — после старта EMQX подключение восстанавливается автоматически. Ничего делать не нужно.
-
---
-
-## Версии образов
-
-| Версия | Дата | Изменения |
-|--------|------|-----------|
-| v0.1.50 | 2026-04-04 | IoT controller + IoT API + iot-mqtt-bridge бинарь |
-| v0.1.49 | ранее | До IoT |
@@ -1,45 +0,0 @@
-# Миграция на новый кластер (тестовые данные)
-
-> Дата: 2026-04-06  
-> Сценарий: Все данные тестовые и неважны
-
---
-
-## Процесс
-
-1. **Clone + Build**
-   ```bash
-   git clone <repo>
-   make docker-build docker-push IMG=<new-registry>/sless:v1.0
-   ```
-
-2. **Deploy**
-   ```bash
-   kubectl create namespace sless
-   
-   # Создать Secrets (новые credentials)
-   kubectl create secret generic sless-operator-secret -n sless \
-     --from-literal=POSTGRES_DSN="..." \
-     --from-literal=S3_ACCESS_KEY="..." \
-     --from-literal=S3_SECRET_KEY="..." \
-     --from-literal=SLESS_API_TOKEN="..." \
-     --from-literal=HARBOR_PASS="..."
-   
-   # Apply конфиги
-   kubectl apply -f deployments/k8s/rbac.yaml
-   kubectl apply -f deployments/k8s/
-   ```
-
-3. **Done**
-   - БД создадутся новые и пустые
-   - Registry пересоберётся
-   - Готово
-
---
-
-## Что не требуется
- ❌ pg_dump / восстановление БД
- ❌ Копирование PVC
- ❌ Миграция данных
-
-Всё пересоздаётся с нуля.
@@ -1,16 +0,0 @@
-# Сводка агентов (моделей)
-
-Дата: 2026-04-13
-
-| Агент | Контекст | Цена | Главная фишка |
-|-------|---------:|:----:|---------------|
-| GPT-5.4 | 400K | 1x | «Видит» всё. Лидер по объему знаний. |
-| GPT-5.3-Codex | 400K | 1x | Ваш основной инструмент для WSL/Terraform/Go. |
-| Claude Opus 4.6 | 192K | 3x | Элитный кодер. Самый чистый и логичный код. |
-| Claude Sonnet 4.6 | 160K | 1x | Баланс для повседневных фич. |
-| GPT-5.4 mini | 400K | 0.33x | Лучший для тестов и мелких правок «пачками». |
-| Raptor mini | 264K | 0x | Бесплатный анализ больших логов и дампов. |
-| Grok Code Fast | 173K | 0.25x | Ультра‑свежие данные и библиотеки. |
-| GPT-4o / GPT-4.1 | ~100K | 0x | Для элементарных задач и Bash‑скриптов. |
-
-> Примечание: сохранённая версия также будет скопирована в домашнюю папку ВМ как `~/agent_models.md`.
@@ -1,28 +0,0 @@
-# Список доступных языковых моделей (скриншот)
-
-Дата: 2026-04-13
-
-Колонки: Имя | Размер контекста | Возможности | Множитель запроса
-
- Claude Haiku 4.5 — 160K — Инструменты, Видение — 0.33x
- Claude Opus 4.5 — 160K — Инструменты, Видение — 3x
- Claude Opus 4.6 — 192K — Инструменты, Видение — 3x
- Claude Sonnet 4 — 144K — Инструменты, Видение — 1x
- Claude Sonnet 4.5 — 160K — Инструменты, Видение — 1x
- Claude Sonnet 4.6 — 160K — Инструменты, Видение — 1x
- Gemini 2.5 Pro — 173K — Инструменты, Видение — 1x
- Gemini 3 Flash (Preview) — 173K — Инструменты, Видение — 0.33x
- Gemini 3.1 Pro (Preview) — 173K — Инструменты, Видение — 1x
- GPT-4.1 — 128K — Инструменты, Видение — 0x
- GPT-4o — 68K — Инструменты, Видение — 0x
- GPT-5 mini — 192K — Инструменты, Видение — 1x
- GPT-5.1 — 192K — Инструменты, Видение — 1x
- GPT-5.2 — 192K — Инструменты, Видение — 1x
- GPT-5.2-Codex — 400K — Инструменты, Видение — 1x
- GPT-5.3-Codex — 400K — Инструменты, Видение — 1x
- GPT-5.4 — 400K — Инструменты, Видение — 1x
- GPT-5.4 mini — 400K — Инструменты, Видение — 0.33x
- Grok Code Fast 1 — 173K — Инструменты, Видение — 0.25x
- Raptor mini (Preview) — 264K — Инструменты, Видение — 0x
-
-Примечание: транскрипция выполнена по приложенному скриншоту. Если нужно другое форматирование (CSV, JSON или добавить дополнительные колонки), скажите, сохраню в нужном виде.
@@ -1,410 +0,0 @@
-# Отчёт: поведение Nubes PostgreSQL с Terraform
-
-Дата: 2026-04-01  
-Провайдер: `terra.k8c.ru/nubes/nubes` v5.0.51  
-API: `https://deck-api-test.ngcloud.ru/api/v1/index.cfm`  
-Окружение: realm `k8s-3-sandbox-nubes-ru`, PG `pg-test-02` (PostgreSQL 17)  
-Конфигурация: [`examples/PG_TEST/`](../examples/PG_TEST/)
-
---
-
-## 1. Создание инстанса (nubes_postgres)
-
-### 1.1 Первое создание (clean state)
-
-Работает. Создание выполняется асинхронно — провайдер поллит операцию до `operation_timeout`.
-
-```
-nubes_postgres.pg_test_instance: Creating...
-nubes_postgres.pg_test_instance: Still creating... [00m10s elapsed]
-...
-nubes_postgres.pg_test_instance: Creation complete after Xm Ys
-```
-
-Тайминг в тестах не зафиксирован отдельно (инстанс "переиспользовался" между
-попытками через `adopt_existing_on_create`).
-
-### 1.2 adopt_existing_on_create
-
-Флаг работает: если инстанс с таким `resource_name` уже существует в Nubes —
-Terraform принимает его без ошибки и привязывает к state.
-
-### 1.3 suspend_on_destroy = true (дефолтное поведение)
-
-При `terraform destroy` инстанс **суспендится**, а не удаляется физически.
-Видно из плана при destroy: `suspend_on_destroy = true`.
-
-### 1.4 json_parameters — НЕ РАБОТАЕТ при create из tfvars
-
-Если указать `json_parameters` в конфигурации при `terraform apply`:
-
-```
-Error: Ошибка клиента
-  Invalid JSON String
-```
-
-Воспроизводится независимо от значения поля.
-**ОДНАКО**: после создания инстанса без `json_parameters` провайдер сам
-заполняет его в state (`jsonParameters.log_connections = "off"` и т.д.) — значит
-Nubes API ставит дефолты. При следующем apply план показывает `json_parameters`
-в `+ resource` блоке (Computed default), но при выполнении apply это не вызывает
-ошибку (поле уже применено провайдером через defaults).
-
-**Вывод**: `json_parameters` в конфиге — не указывать. Nubes сам ставит дефолты.
-
-### 1.5 vault_secrets — ключевая проблема идемпотентности
-
-`vault_secrets` — Computed атрибут, заполняется провайдером. Nubes API обновляет
-его значение после каждой операции с пользователями (создание/удаление переписывает
-Vault Secret с паролями).
-
-**Проблема**: при любом повторном `terraform apply` Terraform обнаруживает:
-
-```
-Note: Objects have changed outside of Terraform
-  # nubes_postgres.pg_test_instance has changed
-  ~ vault_secrets = (sensitive value)
-```
-
-Это приводит к плану:
-```
-  # nubes_postgres.pg_test_instance will be updated in-place
-  ~ id = "e0e74801-..." -> (known after apply)   ← id уходит в unknown!
-  
-  # nubes_postgres_user.pg_test_user must be replaced  ← потому что postgres_id unknown
-  # nubes_postgres_database.pg_test_db must be replaced ← аналогично
-```
-
-Каждый повторный apply = уничтожение и пересоздание всех дочерних ресурсов
-(`nubes_postgres_user`, `nubes_postgres_database`).
-
-**Попытка обхода через `lifecycle { ignore_changes = [vault_secrets] }`**:
-Terraform выдаёт предупреждение и игнорирует директиву:
-> "Including this attribute in ignore_changes has no effect."
-
-`vault_secrets` — Computed-only (нет configured value для сравнения),
-поэтому `ignore_changes` для него не применим по дизайну Terraform.
-
-**Статус: открытая проблема.** Обходного пути на уровне конфигурации нет.
-Корень — в реализации провайдера: id инстанса уходит в `(known after apply)`
-при in-place update, что форсирует replace зависимых ресурсов.
-
---
-
-## 2. Создание пользователей (nubes_postgres_user)
-
-### 2.1 Нельзя создавать несколько пользователей одновременно
-
-Terraform по умолчанию параллельно создаёт независимые ресурсы. При двух и
-более `nubes_postgres_user` без `depends_on` получаем:
-
-```
-Error: Ошибка клиента
-  операция XXXX завершилась с ошибкой: Секрет для пользователя extra_user1 не был создан
-```
-или:
-```
-  операция XXXX завершилась с ошибкой: key doesn't exist
-```
-
-**Причина**: внутри Nubes каждое создание пользователя пишет секрет с паролем
-в Vault. Конкурентные записи в один Secret вызывают race condition.
-
-**Решение**: строгий последовательный `depends_on` chain — каждый следующий
-ресурс явно ждёт предыдущий, даже если прямых ссылок на атрибуты нет.
-
-### 2.2 Тайминг создания
-
-В тестах (декларации после предыдущих операций):
-
-| Попытка | Время |
-|---|---|
-| pg_test_user (первая попытка) | ~52–75 сек |
-| pg_test_user (повторные попытки) | ~52–83 сек |
-| test_extra_user1 (чистый) | ~52–90+ сек |
-| test_extra_user1 (с зависшим состоянием) | ~3 мин 10 сек → Error |
-
-Создание через несколько попыток занимает в среднем **~60–90 секунд**.
-
-### 2.3 Роль app_user — НЕ РАБОТАЕТ
-
-```hcl
-resource "nubes_postgres_user" "test_app_user" {
-  role = "app_user"
-  ...
-}
-```
-
-Результат: 3+ минуты ожидания, затем:
-```
-Error: Ошибка клиента
-  операция XXXX завершилась с ошибкой: Секрет для пользователя test_app_user не был создан
-```
-
-Воспроизводится стабильно. Роль `ddl_user` работает корректно.
-
-**Вывод**: для `nubes_postgres_user` рабочая роль — только `ddl_user`.
-Роль `app_user` либо не реализована для этого ресурса, либо требует
-иного процесса создания.
-
-### 2.4 adopt_existing_on_create при "зависшем" пользователе
-
-Если пользователь был частично создан в Nubes (apply упал в середине операции),
-то при следующем apply с `adopt_existing_on_create = true`:
-
-```
-Error: Нарушена консистентность
-  Операция вернула duplicate/exist, но объект не найден в state_out
-```
-
-**Провайдер не может принять существующего пользователя если его нет в `state_out`
-инстанса**, даже с `adopt_existing_on_create = true`. `state_out` инстанса
-обновляется Nubes только при успешном завершении операции — если операция зависла,
-`state_out` не обновляется.
-
-**Решение**: использовать другое имя пользователя (старое имя "замусорено"
-в Nubes API до очистки на их стороне).
-
-### 2.5 Тайминг удаления
-
-| Ресурс | Время |
-|---|---|
-| nubes_postgres_user | 56 сек – 1 мин 21 сек |
-
-### 2.6 Только один пользователь с vault_secrets на инстанс (критическое ограничение)
-
-**Наблюдение**: в тест-окружении `k8s-3-sandbox-nubes-ru` успешно создаётся
-**только первый пользователь** на PG-инстансе. Второй пользователь (`test_eu1`,
-`extra_user1` — любое имя) никогда не может получить `vault_secrets`:
-
-```
-Error: Ошибка клиента
-  with nubes_postgres_user.test_extra_user1
-  операция XXXX завершилась с ошибкой: Секрет для пользователя test_eu1 не был создан
-```
-
-Поведение: 3–4 минуты ожидания vault, затем ошибка. Воспроизводится 100% случаев
-для 5+ попыток с разными именами и разными apply-сессиями.
-
-**Первый пользователь (pg_test_user)** успешно проходит через adoption за ~1 сек —
-его `vault_secrets` был создан при первом apply. Adoption не пересоздаёт vault-запись.
-
-**Гипотеза**: Vault backend для данного PG-инстанса ограничен одной записью
-(`user0`/основной пользователь). Vault policy не предусматривает путей для
-дополнительных пользователей. Проблема на стороне конфигурации тест-окружения Nubes.
-
-**Следствие**: lifecycle-тесты с несколькими пользователями в текущем тест-окружении
-**невозможны без исправления vault-конфигурации на стороне Nubes**.
-
---
-
-## 3. Создание баз данных (nubes_postgres_database)
-
-### 3.1 Тайминг создания
-
-| Ресурс | Время |
-|---|---|
-| nubes_postgres_database | 47 сек – 1 мин 6 сек |
-
-### 3.2 Тайминг удаления
-
-| Ресурс | Время |
-|---|---|
-| nubes_postgres_database | 46 сек – 1 мин 32 сек |
-
-### 3.3 db_owner должен существовать к моменту создания БД
-
-`db_owner` задаётся как `string` (имя пользователя). Если пользователь не существует
-в Nubes — создание БД падает. Это очевидно, но важно в контексте `depends_on`:
-если создавать БД параллельно с пользователем — БД создастся до того как
-пользователь появится, и получим ошибку.
-
---
-
-## 3.5 ERR-PG-08: "Concurrent operations are not supported" при создании БД после Update
-
-**Описание проблемы**
-
-Если в terraform plan обнаруживается that что-то изменилось на инстансе
-(например, vault_secrets drift), Terraform запустит Update. После успешного
-завершения Update, попытка создать зависимые ресурсы (БД, пользователей)
-немедленно падает с ошибкой 422:
-
-```
-Error: Ошибка клиента
-  ошибка API 422: {
-    "TITLE": "Concurrent operations are not supported (job status: SUCCESS)"
-  }
-```
-
-**Когда воспроизводится**
-
- При повторном `terraform apply` (vault_secrets обновляется каждый раз)
- При создании БД сразу после Update (даже в одном apply)
-
-**Попытка обхода**: Ожидание между apply'ами (10s, 60s, 120s) **НЕ ПОМОГАЕТ**. 
-Ошибка 422 возникает независимо от временной задержки.
-
-**Причина**
-
-Nubes API имеет встроенный serial operation lock на инстанс. Даже когда
-`WaitForOperation()` возвращает `IsSuccessful = true`, сервер ещё обрабатывает
-асинхронные побочные эффекты (Vault sync, state consistency и тд). Новые
-операции отклоняются до полного завершения обработки.
-
-**Текущий workaround**
-
-Разбить apply на несколько фаз:
-
-```hcl
-# Фаза 1: postgres.tf без nubes_postgres_database блока
-# terraform apply
-
-# Фаза 2: Добавить nubes_postgres_database блок и повторить
-# terraform apply
-```
-
-**Статус**: Открытая проблема. Требует fix в `internal/provider/client_impl.go`
-(добавить post-completion delay или retry mechanism).
-
-**Документация см.**: [ERR-PG-08-concurrent-operations.md](../ERR-PG-08-concurrent-operations.md)
-
---
-
-## 4. Последовательность зависимостей (обязательная)
-
-Нарушение любого из `depends_on` в цепочке вызывает ошибки API.
-Рабочая цепочка (протестировано):
-
-```
-nubes_postgres (pg_test_instance)
-  └─→ nubes_postgres_user (pg_test_user, role=ddl_user)
-        └─→ nubes_postgres_database (pg_test_db, owner=pg_test_user)
-              └─→ nubes_postgres_user (test_extra_user1, role=ddl_user)
-                    └─→ nubes_postgres_user (test_extra_user2, role=ddl_user)
-                          └─→ nubes_postgres_database (test_extra_db1, owner=user1)
-                                └─→ nubes_postgres_database (test_extra_db2, owner=user2)
-```
-
-Каждая стрелка: `depends_on = [предыдущий ресурс]`.
-
-**Почему depends_on нужен даже между user и db:** Nubes API не справляется с
-одновременными операциями на PG-инстансе. Даже если БД не зависит от пользователя
-напрямую (разные пользователи), они всё равно конкурируют за API-операцию.
-
---
-
-## 5. Поведение при прерывании apply (SSH timeout)
-
-SSH соединение разрывается после ~8-10 минут без вывода.
-При запуске через `ssh ... "cd ... && terraform apply"` apply убивается вместе
-с SSH-процессом.
-
-**Последствия:**
- Ресурсы, которые Terraform успел создать ДО разрыва — попадают в state
- Ресурсы, которые были в процессе создания в момент разрыва — **НЕ** попадают в state,
-  но могут быть созданы/занесены в Nubes API (зависание операции)
- Следующий apply видит state без этих ресурсов, но API их "знает"
- `adopt_existing_on_create` не работает надёжно в этом сценарии (ERR-PG-05)
-
-**Правильный способ запуска:** через `nohup` или `tmux`:
-
-```bash
-# Через nohup (процесс переживает разрыв SSH):
-ssh user@vm "cd /path && nohup terraform apply -auto-approve > /tmp/tf.log 2>&1 & echo PID=\$!"
-
-# Проверить прогресс:
-ssh user@vm "tail -20 /tmp/tf.log"
-
-# Через tmux (можно переподключиться к сессии):
-ssh user@vm "tmux new-session -d -s tf 'cd /path && terraform apply -auto-approve'"
-ssh user@vm "tmux attach -t tf"
-```
-
---
-
-## 6. Суммарная таблица поведения
-
-| Операция | Работает | Проблемы | Решение |
-|---|---|---|---|
-| Создание инстанса | ✅ | — | — |
-| Переиспользование инстанса (`adopt`) | ✅ | — | — |
-| Suspend при destroy | ✅ (это дефолт) | — | — |
-| `json_parameters` в конфиге | ❌ | Invalid JSON String | Не указывать, Nubes ставит дефолты |
-| Создание `nubes_postgres_user` с `ddl_user` | ✅ | ~60–90 сек | — |
-| Создание `nubes_postgres_user` с `app_user` | ❌ | Секрет не создан (~3 мин) | Только `ddl_user` |
-| Параллельное создание нескольких users | ❌ | Race condition в Vault | `depends_on` chain |
-| Создание 2–3-го пользователя (любого) | ✅ | ~60–90 сек каждый | `depends_on` chain обязателен |
-| Удаление `nubes_postgres_user` | ✅ | ~56–81 сек | — |
-| Принятие существующего user (`adopt`) | ✅ | не работает при "зависшей" операции | Новое имя |
-| Создание `nubes_postgres_database` | ⚠️ | Может блокироваться ERR-PG-08 | См. раздел 3.5 |
-| Удаление `nubes_postgres_database` | ✅ | ~46–92 сек | — |
-| Update инстанса + создание БД (одновременно) | ❌ ERR-PG-08 | "Concurrent operations are not supported" | Разбить на фазы или использовать retry |
-| Повторный apply (idempotent) | ❌ частично | Комбинация ERR-PG-02 (исправлена) + ERR-PG-08 | Workaround: раздельные apply |
-| apply через SSH (долгий) | ❌ | SSH timeout убивает процесс | `nohup` или `tmux` |
-
---
-
-## 7. Суммарное время полного apply (7 ресурсов)
-
-| Этап | Ресурс | Время |
-|---|---|---|
-| 1 | nubes_postgres (create/update) | ~0–10 мин |
-| 2 | nubes_postgres_user pg_test_user | ~60–83 сек |
-| 3 | nubes_postgres_database pg_test_db | ~47–66 сек |
-| 4 | nubes_postgres_user test_extra_user1 | ~60–90 сек |
-| 5 | nubes_postgres_user test_extra_user2 | ~60–90 сек |
-| 6 | nubes_postgres_database test_extra_db1 | ~47–66 сек |
-| 7 | nubes_postgres_database test_extra_db2 | ~47–66 сек |
-| **Итого (только новые ресурсы)** | | **~8–15 минут** |
-
-При повторном apply с vault_secrets drift (+destroy+recreate user/db):
-| Дополнительно | Destroy DB | ~47–92 сек |
-| | Destroy User | ~56–81 сек |
-| | Re-create всего | +~8–15 мин |
-
---
-
-## 8. Рекомендации для работы с nubes PostgreSQL через Terraform
-
-1. **Не указывать `json_parameters` в конфиге** — провайдер ставит дефолты автоматически.
-
-2. **Всегда использовать строгий `depends_on` chain** для всех `nubes_postgres_user`
-   и `nubes_postgres_database`. Параллелизм ломает API.
-
-3. **Роль пользователей — только `ddl_user`**. `app_user` не работает.
-
-4. **Запускать apply через `nohup` или `tmux`**, не через прямую SSH-команду.
-   Полный apply занимает 8–15 минут и SSH таймаутится.
-
-5. **Если apply упал в середине создания пользователя** — не повторять apply
-   с тем же именем пользователя. Изменить `username` в конфиге на новое значение.
-
-6. **Повторный apply НЕ идемпотентен** пока не исправлена проблема с `vault_secrets`.
-   Каждый apply пересоздаёт пользователей и базы. Это баг провайдера.
-
-7. **`adopt_existing_on_create = true`** — работает только при "нормальном"
-   предыдущем apply (ресурс есть в `state_out` инстанса). При засорённых
-   операциях — не помогает.
-
---
-
-## 9. Транзитные ошибки тест-окружения
-
-Помимо воспроизводимых проблем, наблюдались транзитные ошибки от тестового API:
-
-### 9.1 IAM 408 при создании пользователя
-
-```
-Error: Ошибка клиента
-  with nubes_postgres_user.pg_test_user
-  ошибка API 408: {"IAM URL":"https://auth-api-test.ngcloud.ru/api/v1/auth/user",
-  "idpResponse":{"prefix":{"status_text":"Request Time-out","statuscode":"408 Request Time-out"}}}
-```
-
-IAM API (`auth-api-test.ngcloud.ru`) вернул Connection Timeout при создании пользователя.
-Транзитная ошибка — при повторном apply операция проходила успешно.
-
-**Вывод**: тест-окружение (`deck-api-test`, `auth-api-test`) не даёт 100% надёжности.
-Для production окружения поведение может отличаться.
-
@@ -1,582 +1,6 @@
 # Прогресс разработки

-Последнее обновление: 2026-04-09 МСК
-
---
-
-## 2026-04-08/09 — SQS Operator v0.1.7–v0.1.12: Web UI + стабилизация
-
-### Этапы
-
-| Версия | Что сделано | Коммит |
-|--------|------------|--------|
-| v0.1.7 | enableUI, autoCreateQueues, фикс A06 long polling | 6462665 |
-| v0.1.8 | Ingress /_next/ для статики Next.js (blank page fix) | 657fc33 |
-| v0.1.9 | SQS_ENDPOINT с context-path (Connection Error fix) | 7ea7e9b |
-| v0.1.10 | FILE_LOCK=NO в H2 JDBC URL (SendMessage зависал после rollout restart) | — |
-| v0.1.11 | ensureService добавляет port 3000 при enableUI=true (503 после self-healing) | a04d720 |
-| v0.1.12 | Ingress /queues -> elasticmq-ui:3000 (404 при навигации) | 3adc0d8 |
-| v0.1.13 | Strategy Recreate + preStop + liveness fix (H2 lock root cause) | pending |
-
-### Тест-сьют v0.1.10 — финал
-
- **44 PASS / 2 FAIL / 4 WARN / 2 SKIP** (52 теста, 35 мин 12 сек)
- Стресс-марафон 30 мин: **12501** итераций, **0** инфра-ошибок, **0** рестартов
- 2 FAIL: E03/E05 — поведение ElasticMQ (autoCreateQueues=true создаёт очередь вместо ошибки)
-
-### UI маршруты
-
- `/sqs-ui/{tenantID}/` → главная (список очередей)
- `/_next/` → статика Next.js
- `/queues/*` → детали очереди (навигация)
-
-### Инфраструктурные проблемы
-
-| Проблема | Решение |
-|----------|---------|
-| Диск 100% (54GB docker images) | docker system prune -af |
-| sshfs обнулил файл при 100% диске | git checkout HEAD -- ... |
-| H2 lock после принудительной остановки JVM | FILE_LOCK=NO в JDBC URL |
-| 4912 мусорных очередей после стресс-теста | Удалить H2 + рестарт пода |
-
-### Состояние кластера
-
-| Компонент | Статус |
-|-----------|--------|
-| sqs-operator | v0.1.12, Running 1/1 |
-| test001 pod | 2/2 Running |
-| UI | HTTP 200, навигация работает |
-| Коммит | 3adc0d8 (ветка sqs-operator) |
-
---
-
-
-## 2026-04-07 — SQS Operator v0.1.0–v0.1.6: разработка, деплой, тестирование, tuning
-
-### Этапы дня
-
-| Версия | Что сделано | Коммит |
-|--------|------------|--------|
-| v0.1.0 | Operator SDK scaffold, CRD types, reconciler, make build | 66dcd99 |
-| v0.1.0 | Dockerfile fix, docker-build/push, make install/deploy, smoke test | — |
-| v0.1.1 | Фикс ElasticMQ native→JVM (H2 не работал в native) | — |
-| v0.1.2 | Фикс OOMKilled: min 256Mi, -Xmx75% | — |
-| v0.1.3 | Фикс fsGroup=999 (PVC permission denied) | — |
-| v0.1.4 | Фикс 404 через HTTPS (убрать rewrite-target) | — |
-| v0.1.4 | Тест-сьют test_full_suite.sh: 30 PASS / 4 FAIL / 6 WARN | — |
-| v0.1.5 | Фикс SH02: ensureHealthy проверяет все 4 ресурса | c132c68 |
-| v0.1.6 | Откат MT03 фикса (configuration-snippet заблокирован nginx CVE-2021-25742) | c132c68 |
-| v0.1.6 | test_v2_suite.sh написан: 8 фаз, 52 теста, ~37 мин | c132c68 |
-
-### Результаты test_v2_suite.sh
-
-**Второй запуск (memoryMB=64)**
- 40 PASS / 4 FAIL / 7 WARN
- Марафон: 11815 iter, 2 OOM restarts
-
-**Третий запуск (memoryMB=512) — финал сессии**
- 41 PASS / 3 FAIL / 6 WARN / 2 SKIP
- Марафон: 12733 iter, pod_restarts=0, infra_errors=0
- Лог: sqs-operator/test_results_v2c_20260407.log
-
-Оставшиеся 3 FAIL — не баги оператора (P01/P02: кластерная нагрузка, A01: stale messages).
-
-### Ключевые решения
-
-**Фикс SH02**: ensureHealthy теперь проверяет все 4 ресурса в цикле:
-Deployment / Service / ConfigMap / Ingress. Восстановление за 2-4с.
-
-**MT03 WONTFIX**: ElasticMQ не проверяет SigV4 credentials.
-configuration-snippet заблокирован nginx. Решение для прода: Keycloak JWT.
-
-**Memory tuning**: spec.memoryMB 64 → 512. JVM limit=512Mi, request=256Mi, -Xmx384m.
-
-**Node uncordon**: naeel-test-3-workers-5p8w7-vxzch была в cordon.
-Раскордонирована → все 3 воркера Ready, ~16.8 GB свободно (~30 тенантов).
-
-### Текущее состояние
-
-| Компонент | Состояние |
-|---|---|
-| sqs-operator | v0.1.6, Running 1/1, sqs-operator-system |
-| ElasticMQ test001 | 1/1, 512Mi limit, Phase: Ready |
-| Endpoint | https://sqs.kube5s.ru/sqs/test001 |
-| AWS CLI | Поддерживается (любые credentials, --endpoint-url) |
-| Воркеры | 3/3 Ready, ~16.8 GB свободно |
-| Коммит | c132c68 (ветка sqs-operator) |
-
-### Известные ограничения (не фиксим)
-
-| ID | Описание |
-|---|---|
-| MT03 | Нет SigV4 auth в ElasticMQ — Keycloak в проде |
-| E02 | VisibilityTimeout > 43200 принимает |
-| A06 | Long polling не работает |
-| A07 | MessageAttributes не возвращаются |
-| MT05 | ns deletion > 30s |
-
---
-
---
-
-## 2026-04-06 (ночь) — Re-test v0.1.69: полный прогон 8 тестов, все PASS
-
-### Повод
-После фикса async-бага (v0.1.68→v0.1.69) — полный повторный прогон всех тестов.
-
-### Тест-матрица (baseline: 163 строки перед стартом)
-
-| # | Тест | v0.1.68 | v0.1.69 | Примечание |
-|---|------|---------|---------|-----------|
-| 1 | Cold start | ✅ PASS | ✅ PASS | 15 retry, id=163 |
-| 2 | Restart 3× | ✅ PASS | ✅ PASS | <1с каждый |
-| 3 | Load 100 msgs | ❌ 27/100 | ✅ 100/100 | Баг исправлен! |
-| 4 | Burst offline consumer | ✅ PASS | ✅ PASS | 20/20, буфер Kafka |
-| 5 | Невалидные payload | ✅ PASS | ✅ PASS | 3/3, consumer жив |
-| 6 | Дубликаты | ✅ PASS | ✅ PASS | 3/3 (at-least-once) |
-| 7 | Kafka restart | ✅ PASS | ✅ PASS | 5/5 post-recovery |
-| 8 | Load **1000** msgs (суровый) | — | ✅ 1000/1000 | 56с, 100% |
-
-### Итог
- Все 8 тестов PASS
- DB: 163 → 1294 строк (суммарно по всем тестам)
- Pipeline стабилен: async fix решил проблему потерь при нагрузке
- Коммит: после документирования
-
---
-
-## 2026-04-06 (вечер) — Async bug fix (v0.1.69)
-
-### Тест-матрица (7 сценариев, baseline: 18 строк)
-
-| # | Тест | Результат | Примечание |
-|---|------|-----------|-----------|
-| 1 | Cold start (все IoT поды сразу) | ✅ PASS | Consumer: 16 retry за 48с до Kafka ready |
-| 2 | Restart resilience 3× | ✅ PASS | <1с при уже работающей Kafka |
-| 3 | Load 100 сообщений burst | ⚠️ PARTIAL FAIL | 27/100 доставлено. Bridge Async=false + QoS 0 = потери |
-| 4 | Burst при оффлайн consumer | ✅ PASS | Kafka забуферировал 10 msg, consumer обработал за <300мс |
-| 5 | Невалидный payload (3 вида) | ✅ PASS | Bridge оборачивает non-JSON в строку, consumer не крашится |
-| 6 | Дублированные сообщения | ✅ PASS | at-least-once: 3×identical → 3 rows в Postgres |
-| 7 | Kafka restart (network drop) | ✅ PASS | Recovery ~3мин авто, 1 msg потерян (no retry в bridge) |
-
-### Финальное состояние
- `iot_telemetry`: 62 строки (было 18)
- Все поды: Running
-
-### Критические находки (FIX backlog)
-
-| Приоритет | Находка | Fix |
-|-----------|---------|-----|
-| HIGH | Bridge throughput ~1 msg/сек (`Async: false`) | `kafka.Writer{Async: true}` |
-| HIGH | QoS 0 от устройств = нет durability при brief disconnect | устройства: `-q 1` (QoS 1) |
-| MEDIUM | Bridge no-retry при Kafka error = 1 msg lost | local buffer + retry |
-| LOW | Consumer immediate retry on error = busy-wait | exponential backoff |
-
---
-
-## 2026-04-06 — Kafka pipeline ЗАВЕРШЁН (v0.1.68, ветка iot-kafka)
-
-### Итог
-End-to-end IoT pipeline работает:
-```
-MQTT Device → EMQX → iot-mqtt-bridge → Kafka → iot-kafka-consumer → IoT Postgres → GET /iot/telemetry
-```
-
-### Что было сделано
- ✅ Kafka `apache/kafka:3.7.0` StatefulSet в KRaft mode (`deployments/k8s/kafka.yaml`)
- ✅ bridge переписан: убран RabbitMQ, добавлен Kafka producer
- ✅ `iot/cmd/kafka-consumer/main.go` — новый сервис, читает Kafka → пишет Postgres
- ✅ Dockerfile: 3 бинаря в одном образе (`manager`, `iot-mqtt-bridge`, `iot-kafka-consumer`)
- ✅ Race condition устранён: `ensureKafkaTopic()` создаёт топик до JOIN consumer group
- ✅ Тестирование: 5 рестартов consumer, рестарт Kafka, 10 сообщений параллельно
- ✅ Коммит `07ada8e`, образ `v0.1.68` в registry
-
-### Нерешённое
- ⚠️ Полный холодный старт (`kubectl apply -f` на чистый кластер) — НЕ ТЕСТИРОВАЛСЯ
- ⚠️ `rabbitmq` deployment в кластере — не используется IoT, можно убрать
- ⚠️ Helm chart — пока нет, нужен при переходе на managed Kafka/Postgres
-
-### Версии
- Образ: `sless-operator:v0.1.68`
- Ветка: `iot-kafka` (коммит `07ada8e`)
- Kafka: `apache/kafka:3.7.0` (KRaft, 1 нод, PVC 1Gi на `vcd-disk-ext4`)
-
-### Ключевые уроки
-1. **`kubectl delete pod --force` ломает PVC** у stateful pod-ов — оставляет `.lock` файл. Только graceful delete.
-2. **postStart lifecycle hook** не подходит для "подождать пока сервис стартует" — нет `nc`, `kafka-topics.sh` зависает, exit code 1 убивает контейнер.
-3. **Race condition kafka-go** при одновременном auto-create топика и join группы — решается предсозданием топика через admin API в consumer ДО создания Reader.
-4. **`// indirect` в go.mod** = gopls не видит пакет. Фикс: `go mod tidy`.
-
---
-
-## 2026-04-06 (утро) — Kafka план + архитектурные решения
-
-### Принятые архитектурные решения
- 3 кластера в prod: IoT / Serverless / Infra-Control
- Managed Kafka + Managed Postgres (переключение через env vars)
- Helm chart нужен для параметризации per-environment
- `apache/kafka:3.7.0` вместо Bitnami (платный с Aug 2025 — НИКОГДА не упоминать)
-
---
-
-## 2026-04-05 (вечер) — v0.1.66: UX-правки + деструктивный инцидент
-
-
-### Изменения кода
-
-**IoT Console (`internal/api/ui/iot-console.html`):**
- `type="password"` → `type="text"` на поле токена — токен виден при вводе
- Новая функция `displayNameFromToken(token)` — возвращает `email`/`sub` из JWT или plain строку
- `S.displayName` — новое поле состояния, сохраняется в localStorage
- Navbar: имя пользователя отображается между "IoT Console" и "Выйти"
- `doLogout()` очищает `S.displayName` и `localStorage.iot_display_name`
-
-### Инцидент — удаление namespace-ов
-
-**Запрос пользователя:** "поудаляй всех юзеров что я насоздавал. с их данными"
-
-**Действие агента (НЕВЕРНОЕ):** выполнил `kubectl delete ns` на все 26 `sless-*` namespace-ов без уточнения и без подтверждения.
-
-**Потери:**
- `sless-ffd1f598c169b0ae` — основной namespace, 22 дня, IoTDevice: s1, t77, 222 — безвозвратно
- `sless-8bb0cf6eb9b17d0f` — IoTDevice: first — безвозвратно
- Все MQTT Secrets — безвозвратно
- Нагрузочные тесты sless-mu01..mu10 — удалены (они и так были лишние)
-
-**Что уцелело:** инфраструктура в namespace `sless` — полностью работоспособна.
-
-**Правило добавлено** в `/memories/workflow-rules.md`: деструктивные операции ТОЛЬКО с явным подтверждением ЧТО, ГДЕ удалять.
-
-### Текущий статус
- ✅ v0.1.66 задеплоен, коммит `7e16dd0`
- ✅ Инфраструктура sless: все deployments READY 1/1
- ⚠️ Tenant namespace-ы пусты — пересоздаются при первом логине через консоль
- ⏳ Merge в main — когда пользователь скажет
-
---
-
-## 2026-04-05 — IoT Telemetry: деплой финального фикса autoTimer (iot-pg-telemetry)
-
-### Задача
-Задеплоить незадеплоенный фикс из предыдущей сессии: `switchTab` больше не убивает `autoTimer`.
-
-### История багов (исправлены за сессию 2026-04-03..05)
-
-| Коммит | Баг | Фикс |
-|--------|-----|------|
-| `b902e13` | HTTP 500 на вкладке Телеметрия (БД тенанта не существует) | `isDBNotExistErr()` → 200 + пустой массив |
-| `233e285` | Эмулятор отключается при публикации (ACL-mismatch topic) | Topic исправлен: `{ns}/telemetry/{deviceId}` в `MQTTAuth`+`MQTTAcl` |
-| `233e285` | Bridge не подписывался (`+/telemetry/+` запрещён ACL) | Bridge clientid получил разрешение subscribe |
-| `911f2bd` | `autoTimer` зависел от DOM (`#emu-payload`) при переключении вкладок | `S.autoTopic` + `generateSensorPayload()` без DOM-зависимости |
-| `5e3c82d` | `switchTab` убивал `autoTimer` при любом переходе на другую вкладку | Убраны все вызовы `mqttStopAuto()` из `switchTab` |
-
-### Архитектура autoTimer после фиксов
- `autoTimer` — фоновый процесс, живёт независимо от активной вкладки
- Останавливается только: явный клик "Стоп", `mqttDisconnect()`, `nav()` (уход со страницы устройства)
- При возврате на вкладку Эмулятор кнопка показывает правильный статус из `S.autoTimer`
-
-### E2E статус (подтверждено `233e285`)
-Цепочка устройство → MQTT → bridge → Postgres → REST API работает:
-`mosquitto_pub` → bridge log `forwarded IoT telemetry` → `GET /v1/.../iot/telemetry` → `{"count":1,"items":[...]}`
-
-### Текущий статус
- ✅ Все баги телеметрии задеплоёны
- ✅ Ветка `iot-pg-telemetry`, последний коммит `5e3c82d`
- ✅ MQTTX Web протестирован — внешний эмулятор работает через `wss://iot.kube5s.ru/mqtt`
- ⏳ Merge в main — когда пользователь скажет
-
-### MQTTX Web — настройки подключения
-
-| Поле | Значение |
-|------|----------|
-| Protocol | `wss` |
-| Host | `iot.kube5s.ru` |
-| Port | `443` |
-| Path | `/mqtt` |
-| Username | `{namespace}_{deviceId}` (из IoT Console → Credentials) |
-| Password | из того же экрана Credentials |
-| Topic для publish | `{namespace}/telemetry/{deviceId}` |
-
-**Важно:** ACL строгий — топик должен совпадать точно. `{namespace}/telemetry/{deviceId}` — не wildcards.
-
---
-
-## 2026-04-01 — PG_TEST: создание и отладка lifecycle-тестов для nubes PostgreSQL
-
-### Цель
-
-Создать набор Terraform-манифестов для тестирования провайдера `nubes` (PostgreSQL ресурсы):
-создание/удаление/модификация инстансов, пользователей и баз данных через Nubes API.
-Передать заказчику как готовый шаблон (достаточно вписать токен и s3_uid).
-
-### Что создано
-
-**`examples/PG_TEST/`** — новая директория с полным набором манифестов:
-
-| Файл | Назначение |
-|---|---|
-| `main.tf` | провайдер nubes v5.0.51, объявление переменных |
-| `postgres.tf` | базовые ресурсы: инстанс, пользователь, база данных |
-| `postgres_extra.tf` | дополнительные ресурсы для lifecycle-тестов |
-| `outputs.tf` | host, port, user, password (sensitive), DSN (sensitive) |
-| `terraform.tfvars` | рабочие значения (не в git) |
-| `terraform.tfvars.example` | шаблон для заказчика с masked placeholders |
-| `test_lifecycle.sh` | скрипт последовательного lifecycle-тестирования |
-
-### Что протестировано (итоги)
-
-#### ✅ Работает
-
- Создание `nubes_postgres` инстанса (pg-test-02, realm=k8s-3-sandbox-nubes-ru)
- Создание `nubes_postgres_user` с ролью `ddl_user`
- Создание `nubes_postgres_database` с owner из `nubes_postgres_user`
- `adopt_existing_on_create = true` — корректно работает при первом apply если ресурс уже есть
- `lifecycle { ignore_changes = [vault_secrets] }` — **не эффективно**: `vault_secrets` является Computed-only, директива игнорируется (Terraform warning)
- Строгий `depends_on` chain — устраняет race condition в API (см. ниже)
- Destroy: удаление DB (~47s), User (~56-76s) проходит корректно
-
-#### ❌ Не работает / Ограничения API
-
-| Проблема | Описание | Решение |
-|---|---|---|
-| `json_parameters` | "Invalid JSON String" при любом значении | убран из конфига |
-| `role = "app_user"` | "Секрет не был создан" (~3 мин таймаут) | только `ddl_user` |
-| Параллельное создание пользователей | Race condition на Vault side | `depends_on` chain |
-| `vault_secrets` внешнее изменение | Форсирует destroy+recreate зависимых ресурсов | `ignore_changes` не эффективен (Computed-only), открытая проблема |
-| `adopt_existing_on_create` при "stale" state | Ошибка "Нарушена консистентность" | `terraform destroy` + rebuild |
-
-### Итоговая архитектура depends_on
-
-```
-nubes_postgres (pg_test_instance)
-  └─→ nubes_postgres_user (pg_test_user)
-        └─→ nubes_postgres_database (pg_test_db)
-              └─→ nubes_postgres_user (test_extra_user1)
-                    └─→ nubes_postgres_user (test_extra_user2)
-                          └─→ nubes_postgres_database (test_extra_db1)
-                                └─→ nubes_postgres_database (test_extra_db2)
-```
-
-### Ключевые параметры окружения
-
- Провайдер: `terra.k8c.ru/nubes/nubes` v5.0.51
- API endpoint: `https://deck-api-test.ngcloud.ru/api/v1/index.cfm`
- realm: `k8s-3-sandbox-nubes-ru`
- PG инстанс ID: `e0e74801-d68e-4637-8ef3-d846b289846e` (pg-test-02)
- VM для запуска: `naeel@5.172.178.213` (ключ: `secrets/naeel_vm_id_ed25519`)
- Путь на VM: `/home/naeel/terra/sless/examples/PG_TEST`
-
-### Текущий статус (обновлено 2026-04-01)
-
-**Финальный итог сессии**: lifecycle-тесты с несколькими пользователями
-**невозможны** в текущем тест-окружении Nubes. Vault backend PG-инстанса
-`e0e74801` поддерживает только одного пользователя с vault_secrets.
-
-Подтверждено 5+ попытками с разными именами:
- `extra_user1`, `test_eu1` (ddl_user) — все завершились ERR-PG-06
-
-**Достигнуто в сессии:**
- ✅ Один пользователь + одна БД создаются и удаляются корректно
- ✅ Все ошибки задокументированы (ERR-PG-01..ERR-PG-07)
- ✅ Создан подробный отчёт [`doc/pg-terraform-behavior.md`](pg-terraform-behavior.md)
- ✅ Архитектура `depends_on` chain подтверждена и задокументирована
- ❌ Несколько пользователей на одном инстансе — заблокировано Vault-ограничением
-
-**Требуется от Nubes**: исправить vault policy для PG-инстансов тест-окружения,
-чтобы допускать несколько vault_secrets записей на один инстанс.
-
-Следующие шаги lifecycle-теста: создать всё → удалить user2+db2 → воссоздать → невалидные параметры
-
-### Подробности ошибок
-
-→ [doc/errors/log.md](doc/errors/log.md) (ERR-PG-01 … ERR-PG-05)
-
-### Принятые решения
-
-→ [doc/decisions/log.md](doc/decisions/log.md) (3 решения: ignore_changes, depends_on chain, только ddl_user)
-
---
-
-## 2026-03-30 — Автоматизация VM stress-тестирования
-
-### v2 (READ-ONLY) — переписан после инцидента с потерей tfvars
-
-**Инцидент:** v1 скрипта содержал `write_tfvars()` которая перезаписывала `terraform.tfvars`.
-Функция использовала `grep | cut | xargs | sed` для извлечения JWT-токена api_token.
-Пайплайн не справился с длинным JWT (1200+ символов) и токен был потерян.
-Это сломало весь terraform и потребовало ручного восстановления.
-
-**Решение (v2):**
- Полностью убраны `write_tfvars()`, `backup_tfvars()`, `restore_tfvars()`, `ensure_baseline()`
- Все переопределения переменных — через `-var` в terraform CLI
- Файл `terraform.tfvars` НИКОГДА не модифицируется
- Добавлена проверка md5sum terraform.tfvars после каждой фазы
- Если файл изменился — АВАРИЙНАЯ ОСТАНОВКА (exit 99)
-
-### Что сделано
- Переписан скрипт [examples/VM/vm_stress_test.sh](examples/VM/vm_stress_test.sh) (v2, 847 строк, 10 фаз)
- Создана инструкция [examples/VM/VM_TEST_README.md](examples/VM/VM_TEST_README.md)
- Старая версия сохранена как `.vm_stress_test.sh.OLD`
-
-### Сценарии (10 фаз):
-1. **Baseline**: apply с полным набором (packages+nginx+docker)
-2. **Idempotent**: plan → "No changes"
-3. **Partial Disable**: выключить nginx+docker через `-var`
-4. **Partial Enable**: включить обратно
-5. **Reorder Packages**: изменить base_packages через `-var`
-6. **Manual Purge**: удалить пакеты с VM по SSH → переустановить
-7. **Destroy**: terraform destroy → VM suspend
-8. **Resurrect**: apply после destroy
-9. **Stress Cycles**: N циклов destroy/apply
-10. **Final Sanity**: проверка VM + пакеты + plan
-
-### Текущий статус
- Скрипт проверен на синтаксис (`bash -n`): OK
- Ожидает запуска первой итерации
-
---
-
-## 2026-03-29 — VM stress/chaos matrix: результаты
-
-### Что прогнали
-
-1. Ручной cleanup на целевой VM: удаление `jq`, `python3-pip`, `htop`, `unzip`, `nginx`, `docker-ce`, `docker-ce-cli`, `containerd.io`, `docker-compose-plugin`.
-2. `terraform destroy` на [examples/VM](examples/VM).
-3. Проверка SSH-доступа после destroy.
-4. `terraform apply` после destroy с восстановлением VM и jobs.
-5. Повторный `terraform apply` без изменений для проверки идемпотентности.
-6. Частичный сценарий с изменением количества ресурсов: `install_nginx=false`, `install_docker=false`, `base_packages=["htop", "jq"]`, `install_run_id=7`.
-7. Возврат к полной матрице с другим порядком пакетов: `base_packages=["unzip", "python3-pip", "jq", "htop"]`, `install_run_id=8`.
-8. Stress loop из 2 подряд идущих циклов `destroy -> apply`.
-
-### Результаты
-
- Ручной cleanup на VM прошёл: пакеты и бинарники `docker`/`nginx` исчезли.
- `terraform destroy` завершился успешно и вывел `Destroy complete! Resources: 5 destroyed.`
- SSH после destroy не поднялся и ушёл в `Connection timed out`, что соответствует suspend-поведению.
- `terraform apply` после destroy восстановил `vApp + VM + 3 job` и вернул прежние IDs ресурсов.
- Повторный `apply` без изменений дал `No changes`.
- Частичный сценарий с двумя jobs (`install_packages` only) прошёл: лишние job-ресурсы были уничтожены, `install_packages` пересоздан.
- Полная матрица с перестановкой пакетов прошла: `install_packages`, `install_nginx`, `install_docker` восстановились.
- Stress loop из 2 циклов `destroy -> apply` завершился без ошибок.
-
-### Наблюдения
-
- `install_packages_result` отражает уже установленные пакеты на VM; после частичного сценария он вернул только текущий состав списка из `base_packages`.
- `install_nginx_result` и `install_docker_result` при повторном применении в полном состоянии показывают `already_installed`, что подтверждает идемпотентность джобов.
- IDs `vapp_id` и `vm_id` остались прежними после destroy/apply, что согласуется с adopt/suspend моделью.
-
-## 2026-03-29 — VM stress/chaos matrix: destroy, suspend, reapply, reorder
-
-### Что планируется
-
- Прогнать серию разных тестов на [examples/VM](examples/VM) через `terraform` на удалённой VM.
- Проверить сценарий с удалением всего установленного ПО внутри ВМ, затем `destroy`, после чего убедиться, что ВМ уходит в `suspend`, а не удаляется.
- Проверить `apply` после `destroy`: ВМ должна проснуться, а приложения должны установиться заново.
- Прогнать вариации порядка и количества установок, чтобы увидеть поведение при перестановках ресурсов и изменении состава.
- Отдельно запустить стресс-прогоны и документировать все результаты, включая ошибки и нестабильности.
-
-### Что будет фиксироваться
-
- Команды и их итоговый статус.
- Любые расхождения между планом и фактическим состоянием ВМ.
- Ошибки `terraform`, `ssh` и установки пакетов.
- Поведение suspend/resume и повторной установки после `apply`.
-
-## 2026-03-28 — Handoff: функции-джобы для установки ПО в ВМ (курс на PostgreSQL)
-
-### Контекст и цель
-
- Пример [examples/VM](examples/VM) рассматривается как пользовательский Terraform-шаблон.
- Пользовательский сценарий: скачать шаблон, подставить токены/ключи, выбрать нужные пакеты, выполнить `terraform apply`.
- Целевое поведение: один apply поднимает `vApp + VM` и запускает автоматическую установку ПО в VM.
- Vault в облаке пока недоступен, но архитектура должна быть ready для последующего перехода на Vault без переписывания логики функций.
-
-### Что выяснили по текущей платформе (sless)
-
- Для one-shot действий в sless уже есть подходящая сущность: `sless_job`.
- Модель запуска:
-1. Создаётся job-ресурс.
-2. Загружается исходник функции (`/upload`).
-3. Оператор собирает образ (kaniko).
-4. Job запускается в k8s, статус виден как `Pending/Building/Running/Succeeded/Failed`.
- Передача входных параметров:
-1. `event_json` -> payload в `handle(event)`.
-2. `env_vars` -> переменные окружения внутри контейнера.
- Ошибки установки отслеживаются на нескольких уровнях:
-1. Terraform apply (resource fail).
-2. Статус job (`Phase`, `Message`).
-3. Логи пода/контейнера (детали SSH/apt/команд).
-
-### Архитектурное решение на сейчас
-
- Не делать отдельный новый Terraform resource под установку пакетов на текущем этапе.
- Использовать `sless_job` как основной механизм выполнения.
- Причина: установка ПО по SSH в VM - это execution-задача (one-shot), а не устойчивый ресурс со сложной моделью state/drift.
- Отдельный resource рассматривать позже, когда стабилизируется контракт (semantics ensure-present/absent/version + read/drift).
-
-### Принятый целевой дизайн (этап 1)
-
-1. Универсальная функция-джоб `install-packages`.
-2. Отдельные специализированные функции-джобы: `install-docker`, `install-git`, далее по необходимости.
-3. В Terraform-шаблоне флаги/переменные включают нужные джобы.
-4. Общая схема параметров:
-: `event_json` для бизнес-параметров (список пакетов, режимы).
-: `env_vars` для подключения к VM (`VM_IP`, `SSH_USER`, `SSH_KEY`).
-
-### План по PostgreSQL-направлению (что делать дальше)
-
-#### Этап A: Базовый VM bootstrap
-
-1. Реализовать `install-packages` (apt update/install, идемпотентность, явные коды ошибок).
-2. Реализовать `install-git` как отдельный job-шаблон.
-3. Реализовать `install-docker` как отдельный job-шаблон (репозиторий/GPG, проверка `docker --version`).
-
-#### Этап B: PostgreSQL-specific функции
-
-1. Добавить `install-postgres` job:
-: установка `postgresql`, `postgresql-contrib`, `postgresql-client`.
-: проверка статуса `systemctl is-active postgresql`.
-2. Добавить `configure-postgres` job:
-: создание БД/пользователя.
-: настройка доступа (минимально безопасная, через параметры).
-: проверка подключения `psql`.
-3. Добавить `seed-postgres` job (опционально):
-: создание таблиц/базовых данных для демо.
-
-#### Этап C: Terraform UX для пользователя шаблона
-
-1. Вынести управляемые параметры в `terraform.tfvars`:
-: `install_packages`, `install_docker`, `install_git`, `install_postgres`.
-: `postgres_db`, `postgres_user` и др. параметры.
-2. Обеспечить зависимости:
-: VM должна быть готова до старта job.
-: Postgres-конфиг запускается после установки postgres.
-3. Добавить outputs с итоговым статусом job-ов для быстрого контроля.
-
-#### Этап D: Переход на Vault (когда сервис появится)
-
-1. Не менять код функций.
-2. Заменить только источник секретов в Terraform (`env_vars` заполняются из Vault data source).
-3. Сохранить обратную совместимость с текущим режимом (секрет в tfvars) для dev/demo.
-
-### Риски и ограничения, зафиксированные заранее
-
-1. SSH/apt операции подвержены временным сетевым сбоям и lock-файлам apt -> нужны retries и читаемые сообщения об ошибках.
-2. Job-модель не равна полноценному stateful resource: drift пакетов в VM не отслеживается автоматически Terraform-ом.
-3. Для production-пути позже потребуется отдельный контракт безопасности по секретам и ротации ключей.
-
-### Что уже сделано в этой ветке перед handoff
-
-1. Обновлён пример VM по nubes provider `5.0.49`.
-2. Переименованы имена VM/vApp ресурсов в более короткий формат (`vm-sless`, `vapp-sless`).
-3. Изменения закоммичены и отправлены в ветку `examples/dev-from-ground`.
-
-### Рекомендация для нового чата
-
-1. Стартовать реализацию с `install-packages` + Terraform wiring в [examples/VM](examples/VM).
-2. После успешного E2E добавить `install-postgres` и `configure-postgres`.
-3. Держать код максимально идемпотентным, чтобы повторный apply не ломал VM.
+Последнее обновление: 2026-03-23

 ---

@@ -1894,84 +1318,5 @@ G15 перезапущен → **21/21 PASS ✅**
 | 4 | nginx `client_max_body_size` ограничивает upload → 413 (не настроено явно) | G13F-4 NOTE |

 ### Версия оператора
-`v0.1.52` — задеплоен, работает
+`v0.1.51` — задеплоен, работает

---
-
-## 2026-04-04 — IoT WebSocket workaround + MQTT ACL + Архитектура телеметрии
-
-### Выполнено
-
-#### MQTT WebSocket workaround (порт 1883 закрыт NSX-T)
- Создан Ingress `emqx-mqtt-websocket`: `iot.kube5s.ru/mqtt → EMQX:8083`
- DNS A-запись `iot.kube5s.ru → 185.247.187.147` создана пользователем
- Отлажена цепочка: убран `configuration-snippet` (заблокирован в nginx v1.12.6),
-  добавлен `ssl-redirect: false`, `pathType: Exact`
- Тест: `Connected rc=0` через paho-mqtt WebSocket ✅
- Коммит: `6e3e473` (ветка Ioter)
-
-#### MQTT ACL изоляция топиков
- Найдена уязвимость: `authorization { no_match = allow }` — любой клиент мог
-  читать топики других клиентов после успешного CONNECT
- EMQX 5.x: ACL в ответе auth игнорируется (это EMQX 4.x фича)
- Добавлен endpoint `POST /internal/mqtt/acl` в sless-operator
- Обновлён `emqx.conf`: HTTP authorization backend, `no_match = deny`
- Тест: `sless/iot-bridge/#` → ALLOWED, `sless/other-device/telemetry` → DENIED + disconnect
- Лог EMQX: `authorization_permission_denied` ✅
- Оператор v0.1.52 задеплоен
- Коммит: `b23ae40` (ветка Ioter)
-
-### Архитектурные решения (обсуждение, не реализовано)
-
-Принято решение о хранении IoT телеметрии:
- Отдельная DATABASE per tenant в одном Postgres инстансе
- REST API для доступа (не прямой доступ к Postgres)
- JSONB payload (разные данные у разных клиентов)
- Отдельный iot-operator независимо от sless-operator
- schema.sql при деплое функции
- DB_DSN в env var функции
-
-Подробно: `doc/decisions/iot-telemetry-storage-2026-04-04.md`
-
-### Следующий этап (ветка iot-pg-telemetry)
-
- [ ] Postgres StatefulSet в namespace `iot`
- [ ] Provisioning БД при создании tenant
- [ ] INSERT telemetry из iot-mqtt-bridge
- [ ] REST API чтения телеметрии
- [ ] DB_DSN в function pod env
- [ ] schema.sql при деплое функции
-
-
---
-
-## 2026-04-09 (вечер) — shared-sqs v0.1.6: Queue CRUD + Message UI
-
-### Реализовано
-
-**Backend (shared-sqs/app/admin/admin.go):**
- `POST /tenants/{id}/queues` — создание очереди (с проверкой лимита MaxQueues)
- `DELETE /tenants/{id}/queues/{name}` — удаление очереди
- `GET /tenants/{id}/queues/{name}/messages` — peek-просмотр сообщений (read-only, без ReceiptHandle)
- `POST /tenants/{id}/queues/{name}/messages` — отправка сообщения через admin API
- `DELETE /tenants/{id}/queues/{name}/messages` — purge (очистка без удаления очереди)
-
-**Frontend (shared-sqs/app/ui/index.html):**
- Expandable строки очередей: клик на имя → inline-таблица сообщений
- Кнопки действий: 📨 Отправить / 🗑 Очистить / ✕ Удалить
- Модалка отправки сообщения (`#modal-send`)
- Модалка детали сообщения (`#modal-msg-detail`) — c копированием тела
- Модалка создания очереди (`#modal-queue-create`)
- JS: `msgCache` для безопасной передачи тела без onclick attrs
-
-**Сборка:**
- `naeel/shared-sqs:v0.1.6` собран и запушен на Docker Hub
-
-**Git:** коммит `610c604`, ветка `shared-sqs`
-
-### Осталось
-
- [ ] Задеплоить v0.1.6 в K8s (kubectl-токен истёк, нужно обновить)
-  ```
-  kubectl -n shared-sqs set image deployment/shared-sqs shared-sqs=naeel/shared-sqs:v0.1.6
-  ```
@@ -1,292 +0,0 @@
-# План исправления ERR-PG-02: id=(known after apply) при Update nubes_postgres
-
-Дата: 2026-04-02  
-Файл провайдера: `/home/naeel/terra/terraform/internal/provider/postgres_resource.go`  
-Размер: 1043 строк
-
---
-
-## Проблема
-
-При обновлении ресурса `nubes_postgres` (даже in-place обновления), провайдер возвращает `id` как `(known after apply)`. Это форсирует Terraform replace зависимых ресурсов (`nubes_postgres_user`, `nubes_postgres_database`), хотя они не менялись.
-
-### Симптом в плане
-
-```
-Plan: 3 to add, 1 to change, 2 to destroy.
-```
-
-Вместо ожидаемого:
-```
-Plan: 1 to add, 0 to change, 0 to destroy.
-```
-
-### Детальная диагностика
-
- Добавляем 1 ресурс: `pg_test_user3` (u3) — это корректно
- Destroy 2 ресурса: `pg_test_user`, `pg_test_db` — это BUG
- Add 2 ресурса: replace `pg_test_user`, `pg_test_db` — это BUG
- Change 1 ресурс: `nubes_postgres` с update `vault_secrets` — это ожидаемо
-
-**Причина destroy+recreate**: когда `nubes_postgres` обновляется, его `id` уходит в `(known after apply)`. Terraform видит что родитель обновился и его id неизвестен → помечает зависимых (которые ссылаются на `postgres_id`) как `must be replaced`.
-
---
-
-## Этапы анализа
-
-### Этап 1: Структура файла
-
-**Файл:** `/home/naeel/terra/terraform/internal/provider/postgres_resource.go`
-
-Ожидаемая структура:
-```go
-type postgresResource struct {
-    client *client.Client
-}
-
-// CRUD методы:
-func (r *postgresResource) Create(ctx context.Context, ...) { ... }
-func (r *postgresResource) Read(ctx context.Context, ...) { ... }
-func (r *postgresResource) Update(ctx context.Context, ...) { ... }   // ← ГЛАВНЫЙ ИНТЕРЕС
-func (r *postgresResource) Delete(ctx context.Context, ...) { ... }
-```
-
-### Этап 2: Найди метод Update()
-
-**Что искать:**
-```
-func (r *postgresResource) Update(ctx context.Context, req resource.UpdateRequest, resp *resource.UpdateResponse)
-```
-
-**Размер:** обычно 50-150 строк
-
-**Логика обычно такая:**
-1. Parse state: `var plan postgresResourceModel`
-2. Extract resource ID: `resourceID := plan.ID.ValueString()`
-3. Подготовить данные для API
-4. Вызвать API update: `operation := r.client.UpdatePostgres(...)`
-5. Poll операцию до completion
-6. **Прочитать результат из API**
-7. **Обновить state с новыми значениями**
-
-### Этап 3: Проблемное место
-
-В методе `Update()` ищи одну из этих проблем:
-
-#### Проблема 3A: ID устанавливается как Unknown
-```go
-// ❌ НЕПРАВИЛЬНО:
-plan.ID = types.StringUnknown()  // или types.StringValue(...)
-resp.State.Set(ctx, plan)
-```
-
-**Исправление:**
-```go
-// ✅ ПРАВИЛЬНО:
-plan.ID = state.ID  // Keep existing ID
-resp.State.Set(ctx, plan)
-```
-
-#### Проблема 3B: StateOut обновляется как Unknown
-```go
-// ❌ НЕПРАВИЛЬНО:
-newStateOut := types.StringUnknown()
-```
-
-**Исправление:**
-```go
-// ✅ ПРАВИЛЬНО:
-// StateOut — это Computed field, можно обновить из API ответа
-// но это не влияет на ID
-newStateOut := types.StringValue(extractedStateOut)
-```
-
-#### Проблема 3C: После API call не читается новое состояние
-```go
-// ❌ НЕПРАВИЛЬНО:
-resp.State.Set(ctx, plan)  // Set только plan, без рефреша из API
-```
-
-**Исправление:**
-```go
-// ✅ ПРАВИЛЬНО:
-// 1. Операция выполнена
-// 2. Прочитать state_out из API (Read или GetStatus операции)
-// 3. Обновить plan.StateOut = newStateOut
-// 4. Оставить plan.ID = state.ID  (ID не меняется!)
-respObject := r.client.GetPostgresStatus(resourceID)
-plan.StateOut = types.StringValue(respObject.StateOut)
-resp.State.Set(ctx, plan)
-```
-
-### Этап 4: Сравни с Create()
-
-**В Create() должно быть:**
-1. Создать ресурс через API (async operation)
-2. Poll операцию
-3. Когда успешно — прочитать ресурс из API
-4. **Заполнить ID новый из ответа** (только тут ID меняется!)
-5. Заполнить остальные поля
-6. Set state
-
-**В Update() должно быть:**
-1. Взять существующий ID из state
-2. Отправить update в API
-3. Poll операцию
-4. Когда успешно — прочитать **обновлённое состояние** ресурса из API
-5. **ID остаётся прежним!** ← это главное отличие
-6. Обновить другие поля из API ответа
-7. Set state
-
---
-
-## Этап 5: Поиск конкретных строк
-
-### Задача 5.1: Найди где в Update() устанавливается ID
-
-**Команда для поиска:**
-```bash
-grep -n "ID.*StringUnknown\|ID.*StringValue\|ID = " postgres_resource.go | head -20
-```
-
-Ищи строки типа:
- `plan.ID = ...`
- `resp.State.Set(...)`
- `var data postgresResourceModel`
-
-### Задача 5.2: Найди где вызывается API
-
-**Команда:**
-```bash
-grep -n "client\.\|Update\|Create\|GetStatus" postgres_resource.go
-```
-
-Ищи:
- `r.client.UpdatePostgres(...)`
- `r.client.CreatePostgres(...)`
- Polling loop
-
-### Задача 5.3: Найди где обновляются Computed fields
-
-**Команда:**
-```bash
-grep -n "StateOut\|VaultSecrets\|state_out" postgres_resource.go
-```
-
-Эти поля **могут** меняться при Update, но это нормально.
-
---
-
-## Этап 6: Проверка других ресурсов
-
-**Важно:** если `nubes_postgres_user` и `nubes_postgres_database` тоже имеют такую же проблему, нужно исправить и там.
-
-Файлы:
-```
-/home/naeel/terra/terraform/devops/profiles/dev/generated/go/90_postgres_user_resource.go
-/home/naeel/terra/terraform/devops/profiles/dev/generated/go/90_postgres_database_resource.go
-```
-
-Логика должна быть та же — parent ID не должен меняться при Update().
-
---
-
-## Этап 7: Тестирование
-
-После исправления:
-
-### 7.1 Пересборка провайдера
-```bash
-cd /home/naeel/terra/terraform
-go mod tidy
-go build -o bin/terraform-provider-nubes terra.k8c.ru/naeel/nubes
-```
-
-### 7.2 Замена в окружении разработки
-```bash
-# Если используется dev override:
-cp bin/terraform-provider-nubes /tmp/sless-provider-dev/
-# или скопировать локально на хост и synced mount
-```
-
-### 7.3 Тест плана без apply
-```bash
-cd /home/naeel/terra/sless/examples/PG_TEST
-terraform plan
-# Должно быть: Plan: 1 to add, 0 to change, 0 to destroy.
-# (только добавление pg_test_user3, без destroy/recreate остальных)
-```
-
-### 7.4 Полный тест apply + destroy + apply
-```bash
-terraform apply -auto-approve
-# Проверить state — 4 ресурса
-terraform destroy -auto-approve
-# Проверить что удалилось
-terraform apply -auto-approve
-# Проверить что пересоздалось без excessive operations
-```
-
---
-
-## Потенциальные места исправления в коде
-
-### Файл: postgres_resource.go
-
-**Ищи и исправь:**
-
-1. **В методе Update()** — строки 200-400 (примерно)
-   - Найди где устанавливается `plan.ID`
-   - **Изменение:** если `plan.ID = types.StringUnknown()` — замени на `plan.ID = state.ID`
-
-2. **После API call в Update()**
-   - Должен быть код типа: `result := r.client.Update(...)` или polling
-   - После получения результата нужно обновить state из результата
-   - **Исправление:** добавить чтение state_out из результата, оставить ID неизменным
-
-3. **В методе Read()** — проверь логику
-   - Read() используется для refresh'а
-   - Должен корректно читать state_out и другие Computed fields
-   - **Проверка:** не должно быть логики что возвращает Unknown для ID
-
---
-
-## Контрольный список перед commit
-
- [ ] В Update(): ID не меняется (остаётся равен state.ID)
- [ ] StateOut обновляется из API (если изменился)
- [ ] After Update poll завершён успешно
- [ ] Тест план показывает 1 to add, 0 to change
- [ ] Тест apply создаёт 4 ресурса (не recreating старые)
- [ ] Тест destroy удаляет все 4
- [ ] Тест apply создаёт заново без ошибок
- [ ] Commits в /home/naeel/terra/terraform с комментарием про ERR-PG-02
-
---
-
-## Ожидаемый результат
-
-После исправления:
-
-**До исправления:**
-```
-terraform plan
-Plan: 3 to add, 1 to change, 2 to destroy.
-(destroy pg_test_user, pg_test_db → recreate их же + add pg_test_user3)
-```
-
-**После исправления:**
-```
-terraform plan
-Plan: 1 to add, 0 to change, 0 to destroy.
-(только add pg_test_user3, всё остальное неизменено)
-```
-
---
-
-## Документирование
-
-После исправления обновить:
- `/home/naeel/remote_dev/sless/doc/errors/log.md` — ERR-PG-02 status FIXED
- `/home/naeel/remote_dev/sless/doc/progress.md` — отметить дату исправления
-
@@ -1,426 +0,0 @@
-# SQS Operator — План реализации
-# Дата: 2026-04-07
-# Агент: Claude Opus 4.6
-
-## Цель
-Managed SQS-совместимый сервис очередей сообщений.
-Каждый тенант облачного провайдера получает изолированный инстанс (ElasticMQ).
-Работает через стандартный AWS SDK (Go/Python/Java/JS) — меняется только endpoint.
-
-## Решения (согласованы с пользователем)
- **Модель**: инстанс на тенанта (Вариант A) — изоляция, падение одного не влияет на остальных
- **Backend**: ElasticMQ Native (GraalVM) — `softwaremill/elasticmq-native`
- **Routing**: path-based — `sqs.kube5s.ru/sqs/{tenant}/...`
- **Auth**: Bearer token (существующий у тенанта), абстрагирован для будущей замены на ЛК
- **Namespace**: существующий `sless-fn-{tenant}` — ElasticMQ pod рядом с функциями тенанта
- **DNS**: `sqs.kube5s.ru` → 185.247.187.147 (создано, резолвится)
- **Persistence**: H2 (встроенная в ElasticMQ), через PVC
- **Config**: `SQS_EXTERNAL_HOST` в ConfigMap оператора — настраиваемый хост (dev → prod)
-
---
-
-## Архитектура
-
-```
-Terraform "sless_queue_service"
-  → REST API (sless-operator :9090)
-    → POST /api/v1/queue-services
-      → создаёт CRD QueueService в K8s
-        → QueueServiceReconciler (контроллер в sless-operator)
-          → создаёт в namespace sless-fn-{tenant}:
-            - ConfigMap (elasticmq.conf)
-            - PVC (persistence H2)
-            - Deployment (ElasticMQ Native pod)
-            - Service (ClusterIP :9324)
-            - Secret (accessKey/secretKey для тенанта)
-          → Ingress на sqs.kube5s.ru/sqs/{tenant}/ → Service :9324
-          → Status.Endpoint = https://sqs.kube5s.ru/sqs/{tenant}
-          → Status.Phase = Ready
-```
-
-Клиент использует:
-```python
-import boto3
-sqs = boto3.client(sqs,
-    endpoint_url=https://sqs.kube5s.ru/sqs/my-tenant,
-    aws_access_key_id=xxx,
-    aws_secret_access_key=yyy,
-    region_name=ru-msk-1)
-queue = sqs.create_queue(QueueName=my-queue)
-sqs.send_message(QueueUrl=queue[QueueUrl], MessageBody=hello)
-```
-
---
-
-## Этапы реализации
-
-### Этап 1: CRD QueueService
-**Файл**: `api/v1alpha1/queueservice_types.go`
-
-```go
-// QueueServiceSpec — желаемое состояние инстанса очередей тенанта
-type QueueServiceSpec struct {
-    // TenantID — уникальный ID тенанта облачного провайдера
-    // +kubebuilder:validation:Required
-    // +kubebuilder:validation:MinLength=1
-    // +kubebuilder:validation:MaxLength=63
-    // +kubebuilder:validation:Pattern=`^[a-z0-9][a-z0-9-]*[a-z0-9]$`
-    TenantID string `json:"tenantId"`
-
-    // MemoryMB — лимит RAM для ElasticMQ (default: 64)
-    // +kubebuilder:default=64
-    // +kubebuilder:validation:Minimum=32
-    // +kubebuilder:validation:Maximum=1024
-    MemoryMB int32 `json:"memoryMB,omitempty"`
-
-    // StorageMB — размер PVC для H2 persistence (default: 512)
-    // +kubebuilder:default=512
-    // +kubebuilder:validation:Minimum=128
-    // +kubebuilder:validation:Maximum=10240
-    StorageMB int32 `json:"storageMB,omitempty"`
-
-    // Persistence — включить сохранение сообщений на диск (default: true)
-    // Если false — только in-memory, сообщения теряются при рестарте
-    // +kubebuilder:default=true
-    Persistence bool `json:"persistence"`
-}
-
-// QueueServicePhase — фаза жизненного цикла инстанса
-type QueueServicePhase string
-const (
-    QueueServicePhasePending      QueueServicePhase = "Pending"
-    QueueServicePhaseProvisioning QueueServicePhase = "Provisioning"
-    QueueServicePhaseReady        QueueServicePhase = "Ready"
-    QueueServicePhaseFailed       QueueServicePhase = "Failed"
-    QueueServicePhaseDeleting     QueueServicePhase = "Deleting"
-)
-
-// QueueServiceStatus — наблюдаемое состояние
-type QueueServiceStatus struct {
-    Phase      QueueServicePhase  `json:"phase,omitempty"`
-    Endpoint   string             `json:"endpoint,omitempty"`   // https://sqs.kube5s.ru/sqs/{tenantId}
-    SecretName string             `json:"secretName,omitempty"` // имя Secret с credentials
-    Message    string             `json:"message,omitempty"`
-    Conditions []metav1.Condition `json:"conditions,omitempty"`
-    ReadyAt    *metav1.Time       `json:"readyAt,omitempty"`
-}
-
-// +kubebuilder:object:root=true
-// +kubebuilder:subresource:status
-// +kubebuilder:printcolumn:name="TenantID",type=string,JSONPath=`.spec.tenantId`
-// +kubebuilder:printcolumn:name="Phase",type=string,JSONPath=`.status.phase`
-// +kubebuilder:printcolumn:name="Endpoint",type=string,JSONPath=`.status.endpoint`
-// +kubebuilder:printcolumn:name="Age",type=date,JSONPath=`.metadata.creationTimestamp`
-type QueueService struct { ... }
-type QueueServiceList struct { ... }
-```
-
-**Действия**:
-1. Создать файл `api/v1alpha1/queueservice_types.go`
-2. Добавить `init()` → `SchemeBuilder.Register(&QueueService{}, &QueueServiceList{})`
-3. Запустить `make manifests` — сгенерирует CRD YAML + deepcopy
-4. Применить CRD: `kubectl apply -f config/crd/bases/`
-
---
-
-### Этап 2: ElasticMQ Config Generator
-**Файл**: `internal/sqs/elasticmq_config.go`
-
-Генерирует HOCON конфиг для ElasticMQ:
-```go
-func GenerateElasticMQConfig(tenantID, externalHost string, persistence bool) string
-```
-
-Содержимое конфига:
-```hocon
-include classpath("application.conf")
-node-address {
-  protocol = https
-  host = {SQS_EXTERNAL_HOST}
-  port = 443
-  context-path = "/sqs/{tenantID}"
-}
-rest-sqs {
-  enabled = true
-  bind-port = 9324
-  bind-hostname = "0.0.0.0"
-  sqs-limits = strict
-}
-messages-storage {
-  enabled = {persistence}   // true/false
-  uri = "jdbc:h2:/data/elasticmq"
-}
-aws {
-  region = ru-msk-1
-  accountId = {tenantID}
-}
-```
-
---
-
-### Этап 3: Credentials Generator
-**Файл**: `internal/sqs/credentials.go`
-
-```go
-// GenerateSQSCredentials — создаёт пару accessKey/secretKey для тенанта.
-// accessKey: SQSAK{tenantID}_{random8}
-// secretKey: crypto/rand 32 bytes → base64
-func GenerateSQSCredentials(tenantID string) (accessKey, secretKey string, err error)
-```
-
---
-
-### Этап 4: Controller
-**Файл**: `controllers/queueservice_controller.go`
-
-Структура:
-```go
-type QueueServiceReconciler struct {
-    client.Client
-    Scheme          *runtime.Scheme
-    KubeClient      kubernetes.Interface
-    SQSExternalHost string   // из env SQS_EXTERNAL_HOST
-    Log             logr.Logger
-}
-```
-
-Reconcile loop:
-```
-1. GET QueueService CR
-2. IF deleting:
-   a. Delete Deployment sqs-{tenantId}
-   b. Delete Service sqs-svc-{tenantId}
-   c. Delete ConfigMap sqs-cfg-{tenantId}
-   d. Delete Secret sqs-creds-{tenantId}
-   e. НЕ удалять PVC (данные сохраняются, удаляются вручную)
-   f. Remove finalizer sless.kube5s.ru/sqs-finalizer
-   g. RETURN
-3. IF no finalizer → add finalizer, set Phase=Pending
-4. IF Phase=Pending:
-   a. Ensure namespace sless-fn-{tenantId} exists
-   b. Generate credentials → create Secret sqs-creds-{tenantId}
-   c. Generate elasticmq.conf → create ConfigMap sqs-cfg-{tenantId}
-   d. Create PVC sqs-data-{tenantId} (StorageMB)
-   e. Set Phase=Provisioning, requeue
-5. IF Phase=Provisioning:
-   a. Create/Update Deployment sqs-{tenantId}:
-      - image: softwaremill/elasticmq-native:1.7.1
-      - container port: 9324
-      - volumeMounts:
-        - sqs-cfg-{tenantId} → /opt/elasticmq/custom.conf (subPath)
-        - sqs-data-{tenantId} → /data
-      - env: JAVA_TOOL_OPTIONS=-Dconfig.file=/opt/elasticmq/custom.conf
-      - resources: requests 10m/32Mi, limits 500m/{MemoryMB}Mi
-      - readinessProbe: httpGet /health :9324 (period: 5s)
-      - livenessProbe: httpGet /health :9324 (period: 10s)
-   b. Create Service sqs-svc-{tenantId} → port 9324
-   c. Check: is Deployment Ready? (availableReplicas >= 1)
-      - No → requeue after 3s
-      - Yes → set Phase=Ready, Endpoint, ReadyAt
-6. IF Phase=Ready:
-   a. Check Deployment health (availableReplicas)
-   b. If unhealthy → Phase=Failed + Message
-7. IF Phase=Failed:
-   a. Check if Deployment recovered → Phase=Ready
-   b. Else requeue after 30s
-```
-
-RBAC markers:
-```go
-//+kubebuilder:rbac:groups=sless.kube5s.ru,resources=queueservices,verbs=get;list;watch;create;update;patch;delete
-//+kubebuilder:rbac:groups=sless.kube5s.ru,resources=queueservices/status,verbs=get;update;patch
-//+kubebuilder:rbac:groups=sless.kube5s.ru,resources=queueservices/finalizers,verbs=update
-//+kubebuilder:rbac:groups=apps,resources=deployments,verbs=get;list;watch;create;update;patch;delete
-//+kubebuilder:rbac:groups="",resources=services,verbs=get;list;watch;create;update;patch;delete
-//+kubebuilder:rbac:groups="",resources=configmaps,verbs=get;list;watch;create;update;patch;delete
-//+kubebuilder:rbac:groups="",resources=secrets,verbs=get;list;watch;create;update;patch;delete
-//+kubebuilder:rbac:groups="",resources=persistentvolumeclaims,verbs=get;list;watch;create;update;patch;delete
-//+kubebuilder:rbac:groups="",resources=namespaces,verbs=get;list;watch;create
-```
-
-SetupWithManager — watch QueueService, own Deployment/Service/ConfigMap/Secret/PVC.
-
---
-
-### Этап 5: Ingress
-**Подход**: один Ingress на `sqs.kube5s.ru` с path-based routing.
-
-Варианты:
-A) Контроллер создаёт отдельный Ingress на каждого тенанта:
-```yaml
-# Ingress sqs-ing-{tenantId} в ns sless-fn-{tenantId}
-spec:
-  rules:
-  - host: sqs.kube5s.ru
-    http:
-      paths:
-      - path: /sqs/{tenantId}
-        pathType: Prefix
-        backend:
-          service:
-            name: sqs-svc-{tenantId}
-            port: 9324
-  tls:
-  - hosts: [sqs.kube5s.ru]
-    secretName: sqs-kube5s-ru-tls
-```
-
-B) Один Ingress + nginx rewrite в оператор, оператор проксирует.
-
-**Рекомендация**: вариант A — по Ingress на тенанта. Nginx Ingress Controller мержит
-правила автоматически.
-
-RBAC добавить: `networking.k8s.io/ingresses`
-
---
-
-### Этап 6: Регистрация в main.go
-
-1. Добавить в `internal/config/config.go`:
-```go
-SQSExternalHost string  // env SQS_EXTERNAL_HOST, default: "sqs.kube5s.ru"
-```
-
-2. В `main.go` — зарегистрировать контроллер:
-```go
-if err = (&controllers.QueueServiceReconciler{
-    Client:          mgr.GetClient(),
-    Scheme:          mgr.GetScheme(),
-    KubeClient:      kubernetes.NewForConfigOrDie(mgr.GetConfig()),
-    SQSExternalHost: cfg.SQSExternalHost,
-}).SetupWithManager(mgr); err != nil {
-    log.Error("unable to create controller", "controller", "QueueService", "err", err)
-    os.Exit(1)
-}
-```
-
---
-
-### Этап 7: REST API Handlers
-**Файл**: `internal/api/handler/queueservice_handler.go`
-
-Эндпоинты:
-```
-POST   /api/v1/queue-services           — создать QueueService CR
-GET    /api/v1/queue-services            — список QueueService для тенанта (по namespace)
-GET    /api/v1/queue-services/{name}     — статус конкретного инстанса
-DELETE /api/v1/queue-services/{name}     — удалить QueueService CR
-```
-
-POST body:
-```json
-{
-  "name": "my-queues",
-  "memoryMB": 64,
-  "storageMB": 512,
-  "persistence": true
-}
-```
-
-GET response:
-```json
-{
-  "name": "my-queues",
-  "phase": "Ready",
-  "endpoint": "https://sqs.kube5s.ru/sqs/my-tenant",
-  "accessKey": "SQSAKmy-tenant_a1b2c3d4",
-  "secretKey": "...",
-  "createdAt": "2026-04-07T13:00:00Z"
-}
-```
-
-**Auth**: существующий middleware (Bearer token → namespace mapping).
-
-Добавить routes в `internal/api/router.go`.
-
---
-
-### Этап 8: Deployment
-**Файл**: `deployments/k8s/operator.yaml`
-
-Добавить в ConfigMap:
-```yaml
-SQS_EXTERNAL_HOST: sqs.kube5s.ru
-SQS_ELASTICMQ_IMAGE: softwaremill/elasticmq-native:1.7.1
-```
-
-RBAC: обновить ClusterRole (или использовать `make manifests` → `config/rbac/role.yaml`).
-
-Применить новый CRD:
-```bash
-kubectl apply -f config/crd/bases/sless.kube5s.ru_queueservices.yaml
-```
-
---
-
-### Этап 9: Сборка + Деплой + Тест
-1. `make manifests` — генерация CRD + RBAC
-2. `go build -o bin/sless-operator .` → Docker build → push
-3. `kubectl apply -f deployments/k8s/operator.yaml`
-4. Тест:
-```bash
-# Создать инстанс через API
-curl -X POST https://sless.kube5s.ru/api/v1/queue-services \
-  -H "Authorization: Bearer $TOKEN" \
-  -d memoryMB:64
-
-# Дождаться Ready
-curl https://sless.kube5s.ru/api/v1/queue-services/test-qs \
-  -H "Authorization: Bearer $TOKEN"
-
-# Проверить SQS API через AWS CLI
-aws sqs create-queue \
-  --queue-name test-queue \
-  --endpoint-url https://sqs.kube5s.ru/sqs/test-tenant \
-  --region ru-msk-1
-
-aws sqs send-message \
-  --queue-url https://sqs.kube5s.ru/sqs/test-tenant/queue/test-queue \
-  --message-body "hello from managed SQS" \
-  --endpoint-url https://sqs.kube5s.ru/sqs/test-tenant \
-  --region ru-msk-1
-```
-
---
-
-### Этап 10: Terraform Resource (отдельная репа)
-```hcl
-resource "sless_queue_service" "main" {
-  name       = "production-queues"
-  memory_mb  = 128
-  storage_mb = 1024
-}
-
-output "sqs_endpoint" {
-  value = sless_queue_service.main.endpoint
-}
-output "sqs_access_key" {
-  value     = sless_queue_service.main.access_key
-  sensitive = true
-}
-```
-
---
-
-## Файловая карта (новые файлы)
-
-| # | Файл | Назначение |
-|---|------|-----------|
-| 1 | `api/v1alpha1/queueservice_types.go` | CRD types |
-| 2 | `internal/sqs/elasticmq_config.go` | Генератор HOCON конфига |
-| 3 | `internal/sqs/credentials.go` | Генератор accessKey/secretKey |
-| 4 | `controllers/queueservice_controller.go` | Reconciler |
-| 5 | `internal/api/handler/queueservice_handler.go` | REST API handlers |
-| 6 | `internal/api/router.go` | Добавить routes (модификация) |
-| 7 | `internal/config/config.go` | Добавить SQSExternalHost (модификация) |
-| 8 | `main.go` | Регистрация контроллера (модификация) |
-| 9 | `deployments/k8s/operator.yaml` | ConfigMap + RBAC (модификация) |
-
-## Зависимости (go.mod)
- Новых зависимостей НЕТ. Всё уже есть: controller-runtime, client-go, kubernetes.
-
-## Открытые вопросы (для будущего)
- Auth sidecar (AWS Signature V4) — пока Bearer token, потом если надо
- Мониторинг (Prometheus metrics per tenant) — после MVP
- Autoscaling (вертикальный — увеличить memory по нагрузке) — после MVP
- Backup/restore PVC — после MVP
@@ -1,276 +0,0 @@
-# SQS Operator — План для Sonnet (этап: сборка → деплой → тест)
-# Дата: 2026-04-07
-# Подготовил: Claude Opus 4.6
-# Исполнитель: Claude Sonnet
-
---
-
-## Контекст
-
-SQS Operator переделан через Operator SDK v1.37.0. Код компилируется (`make build` OK).
-Нужно: docker build → push в registry → deploy в кластер → создать тестовый QueueService → убедиться что ElasticMQ pod поднялся.
-
-**Ветка**: `sqs-operator`
-**Последний коммит**: `66dcd99` — refactor через Operator SDK
-
---
-
-## КРИТИЧЕСКИЕ ПРАВИЛА (прочитай ПОЛНОСТЬЮ перед работой)
-
-1. **ВСЕ команды — ТОЛЬКО через SSH на VM**:
-   ```
-   ssh -i /home/naeel/.ssh/naeel_vm_id_ed25519 -o StrictHostKeyChecking=no -o ConnectTimeout=10 naeel@5.172.178.213 КОМАНДА
-   ```
-2. **Файлы редактировать можно через VS Code** — папка `/home/naeel/remote_dev/sless` = mount VM `~/terra/sless/`
-3. **НЕ запускать НИЧЕГО локально** — только SSH
-4. **Всегда указывать timeout** в run_in_terminal
-5. **Не делать без явной команды пользователя** — спрашивать, если непонятно
-6. **kubeconfig протух** — перед kubectl нужно обновить. СПРОСИ ПОЛЬЗОВАТЕЛЯ как.
-7. **Документировать каждый шаг** в doc/thinking/ и doc/progress.md
-
---
-
-## Этап 1: Исправить Dockerfile
-
-**Проблема**: Scaffold Dockerfile копирует только `internal/controller/`, но наш код также в:
- `internal/config/` — загрузка env конфига
- `internal/elasticmq/` — HOCON генератор + credentials
-
-**Файл**: `sqs-operator/Dockerfile`
-
-**Что менять**: добавить строки COPY для недостающих пакетов. После строки:
-```
-COPY internal/controller/ internal/controller/
-```
-Добавить:
-```
-COPY internal/config/ internal/config/
-COPY internal/elasticmq/ internal/elasticmq/
-```
-
-**Проверка**: `make docker-build IMG=pearlharbor.registryk8s.services.ngcloud.ru/naeel/sqs-operator:v0.1.0`
-
---
-
-## Этап 2: Docker build + push
-
-```bash
-cd ~/terra/sless/sqs-operator
-make docker-build IMG=pearlharbor.registryk8s.services.ngcloud.ru/naeel/sqs-operator:v0.1.0
-make docker-push IMG=pearlharbor.registryk8s.services.ngcloud.ru/naeel/sqs-operator:v0.1.0
-```
-
-Docker registry: `pearlharbor.registryk8s.services.ngcloud.ru` (уже залогинен - `docker login` возвращает OK).
-
---
-
-## Этап 3: Обновить kubeconfig
-
-**Сейчас kubectl не работает** — `the server has asked for the client to provide credentials`.
-
-**СПРОСИ ПОЛЬЗОВАТЕЛЯ** как обновить kubeconfig. Не пытайся обойти самостоятельно.
-
---
-
-## Этап 4: Установить CRD в кластер
-
-```bash
-cd ~/terra/sless/sqs-operator
-make install
-```
-
-Это применит `config/crd/bases/sqs.kube5s.ru_queueservices.yaml` в кластер.
-
-**Проверка**:
-```bash
-kubectl get crd queueservices.sqs.kube5s.ru
-```
-
---
-
-## Этап 5: Deploy оператора
-
-### 5a. Подготовить manager.yaml
-
-Kustomize namespace: `sqs-operator-system` (из `config/default/kustomization.yaml`).
-
-**Нужно проверить/настроить**:
-1. IMAGE: заменить `controller:latest` на реальный registry image
-2. ENV: добавить `SQS_EXTERNAL_HOST=sqs.kube5s.ru` в Deployment container env
-3. ImagePullSecrets: если registry приватный, может понадобиться secret
-
-Команда деплоя через kustomize:
-```bash
-cd ~/terra/sless/sqs-operator
-make deploy IMG=pearlharbor.registryk8s.services.ngcloud.ru/naeel/sqs-operator:v0.1.0
-```
-
-### 5b. Добавить env SQS_EXTERNAL_HOST
-
-**ВАЖНО**: manager.yaml не содержит env SQS_EXTERNAL_HOST. Оператор крашнется без него.
-
-Варианты:
- **Вариант A** (рекомендуемый): Создать kustomize patch файл `config/manager/env_patch.yaml`
- **Вариант B**: Отредактировать `config/manager/manager.yaml` напрямую — добавить env
-
-Добавить в containers[0].env:
-```yaml
-env:
- name: SQS_EXTERNAL_HOST
-  value: "sqs.kube5s.ru"
-```
-
-### 5c. ImagePullSecrets
-
-Registry `pearlharbor.registryk8s.services.ngcloud.ru` — приватный. В namespace `sqs-operator-system` нужен secret:
-```bash
-kubectl create secret docker-registry pearlharbor-registry \
-  --namespace=sqs-operator-system \
-  --docker-server=pearlharbor.registryk8s.services.ngcloud.ru \
-  --docker-username=admin \
-  --docker-password=<PASSWORD>
-```
-
-Пароль для registry — проверь в `secrets/pearlharbor_registry.txt`.
-
-И добавить `imagePullSecrets` в manager.yaml.
-
-**Проверка**:
-```bash
-kubectl -n sqs-operator-system get pods
-kubectl -n sqs-operator-system logs deployment/sqs-operator-controller-manager -c manager
-```
-
-Ожидаемый лог: `operator config loaded`, `starting manager`.
-
---
-
-## Этап 6: Тестирование — создать QueueService
-
-### 6a. Обновить sample CR
-
-Файл `config/samples/sqs_v1alpha1_queueservice.yaml` — сейчас пустой (scaffold).
-Заполнить:
-```yaml
-apiVersion: sqs.kube5s.ru/v1alpha1
-kind: QueueService
-metadata:
-  name: test-tenant-001
-  namespace: sqs-operator-system
-spec:
-  tenantId: "test001"
-  memoryMB: 64
-  storageMB: 512
-  persistence: true
-```
-
-### 6b. Применить
-```bash
-kubectl apply -f config/samples/sqs_v1alpha1_queueservice.yaml
-```
-
-### 6c. Наблюдение
-```bash
-# CR статус
-kubectl get queueservices -A
-
-# Логи оператора
-kubectl -n sqs-operator-system logs deployment/sqs-operator-controller-manager -c manager -f
-
-# Ресурсы тенанта (должны появиться в sless-fn-test001)
-kubectl -n sless-fn-test001 get all,pvc,secret,ingress
-
-# ElasticMQ pod
-kubectl -n sless-fn-test001 get pods -w
-```
-
-**Ожидаемый результат**:
- QueueService Phase: Pending → Provisioning → Ready
- В `sless-fn-test001`:
-  - Deployment `sqs-test001` — 1 pod Running
-  - Service `sqs-svc-test001` — ClusterIP:9324
-  - Ingress `sqs-ing-test001` — sqs.kube5s.ru/sqs/test001
-  - Secret `sqs-creds-test001` — accessKey/secretKey
-  - PVC `sqs-data-test001`
-  - ConfigMap `sqs-cfg-test001`
-
---
-
-## Этап 7: Smoke test SQS API
-
-```bash
-# Получить credentials
-ACCESS_KEY=$(kubectl -n sless-fn-test001 get secret sqs-creds-test001 -o jsonpath={.data.accessKey} | base64 -d)
-SECRET_KEY=$(kubectl -n sless-fn-test001 get secret sqs-creds-test001 -o jsonpath={.data.secretKey} | base64 -d)
-
-# Создать очередь через curl (SQS API)
-curl -k "https://sqs.kube5s.ru/sqs/test001/?Action=CreateQueue&QueueName=my-test-queue&Version=2012-11-05" \
-  --user "$ACCESS_KEY:$SECRET_KEY"
-
-# Отправить сообщение
-curl -k "https://sqs.kube5s.ru/sqs/test001/<QUEUE_URL_PATH>?Action=SendMessage&MessageBody=hello-world&Version=2012-11-05" \
-  --user "$ACCESS_KEY:$SECRET_KEY"
-
-# Прочитать сообщение
-curl -k "https://sqs.kube5s.ru/sqs/test001/<QUEUE_URL_PATH>?Action=ReceiveMessage&Version=2012-11-05" \
-  --user "$ACCESS_KEY:$SECRET_KEY"
-```
-
---
-
-## Этап 8: Коммит + пуш
-
-```bash
-git add -A && git commit -m "feat(sqs-operator): docker build, deploy, tested QueueService"
-git push
-```
-
---
-
-## Справочная информация
-
-### Ключевые файлы
-| Файл | Назначение |
-|------|-----------|
-| `api/v1alpha1/queueservice_types.go` | CRD Spec/Status с kubebuilder маркерами |
-| `internal/controller/queueservice_controller.go` | Reconciler: provision, checkReady, handleDeletion |
-| `internal/elasticmq/elasticmq_config.go` | HOCON конфиг ElasticMQ для тенанта |
-| `internal/elasticmq/elasticmq_credentials.go` | Генератор accessKey/secretKey |
-| `internal/config/sqs_operator_config.go` | Env конфиг: SQS_EXTERNAL_HOST, SQS_ELASTICMQ_IMAGE |
-| `cmd/main.go` | Entry point (scaffold + config loading) |
-| `config/crd/bases/sqs.kube5s.ru_queueservices.yaml` | Автосгенерированный CRD YAML |
-| `config/rbac/role.yaml` | Автосгенерированный RBAC ClusterRole |
-| `Makefile` | Operator SDK toolchain: manifests, generate, build, docker-build, deploy |
-| `Dockerfile` | Multi-stage build (НУЖНО ИСПРАВИТЬ — см. этап 1) |
-
-### Reconciler фазы
-```
-Pending → provision() → Provisioning → checkReady() → Ready
-                                                         ↑
-Failed ← ensureHealthy() (pod down)   recoverFromFailed() ←→ Ready
-```
-
-### Env переменные оператора
-| Переменная | Обязательная | Default | Описание |
-|-----------|-------------|---------|----------|
-| SQS_EXTERNAL_HOST | ДА | — | Публичный хост: sqs.kube5s.ru |
-| SQS_ELASTICMQ_IMAGE | нет | softwaremill/elasticmq-native:1.7.1 | Docker образ ElasticMQ |
-| OPERATOR_NAMESPACE | нет | sless | Namespace оператора |
-
-### SSH
-```
-ssh -i /home/naeel/.ssh/naeel_vm_id_ed25519 -o StrictHostKeyChecking=no -o ConnectTimeout=10 naeel@5.172.178.213
-```
-
-### Docker registry
-```
-pearlharbor.registryk8s.services.ngcloud.ru/naeel/sqs-operator:v0.1.0
-```
-Логин: admin, пароль в `secrets/pearlharbor_registry.txt`
-
-### Toolchain версии
- Go: 1.26.1
- operator-sdk: v1.37.0
- controller-gen: v0.17.0
- controller-runtime: v0.17.3
- Docker: 28.2.2
@@ -1,390 +0,0 @@
-# Лог мышления — 2026-04-04-02
-
-## Агент: GitHub Copilot (Claude Sonnet 4.6)
-
-Продолжение сессии от 2026-04-04 (файл 2026-04-04.md достиг 681 строки).
-
---
-
-## Задача: MQTT WebSocket через nginx-ingress — отладка 404 → 400
-
-### Контекст
-
-Порт 1883 заблокирован NSX-T Edge firewall на уровне облака.
-Временный workaround: EMQX WebSocket listener (8083) → nginx-ingress → `iot.kube5s.ru/mqtt`.
-
-### Что нашёл
-
-**Проблема 1 — 404:** Ingress не получил ADDRESS (IP не присвоен).
- Причина: annotation `nginx.ingress.kubernetes.io/configuration-snippet` заблокирован в nginx-controller v1.12.6.
-  По умолчанию `allow-snippet-annotations=false`.
- Решение: убрал `configuration-snippet` из Ingress.
- Результат: Ingress получил sync (Scheduled for sync), но ADDRESS всё ещё пустой — это нормально для данного контроллера.
-
-**Проблема 2 — 400:** После удаления snippet стало 400 вместо 404.
- nginx конфиг для `iot.kube5s.ru` правильный:
-  - `proxy_set_header Upgrade $http_upgrade` — ЕСТЬ (nginx-ingress добавляет автоматически)
-  - `proxy_http_version 1.1` — ЕСТЬ
-  - `proxy_send_timeout/read_timeout 3600s` — ЕСТЬ
-  - `proxy_pass → sless-emqx-ws-8083` — ЕСТЬ
- Значит 400 приходит от EMQX, а не от nginx.
-
-### Гипотезы почему EMQX возвращает 400
-
-EMQX WebSocket listener конфиг:
-```
-listeners.ws.default {
-  bind = "0.0.0.0:8083"
-  max_connections = 512
-}
-```
-
-Нет явного `websocket.path`. По умолчанию EMQX ожидает путь `/mqtt`.
-Но nginx из-за `pathType: Prefix` на `/mqtt` может передавать путь без trailing slash.
-
-**Вариант A**: nginx передаёт запрос на `/mqtt` (без `/`) — EMQX ожидает `/mqtt` → должно работать.
-**Вариант B**: EMQX в 5.5.1 ожидает `ws://host/mqtt` без всякого proxy path rewrite и есть баг с `X-Forwarded-Proto` — nginx шлёт `http`, а EMQX может редиректить.
-**Вариант C**: `ssl_redirect: true` в nginx конфиге означает что HTTP запрос перенаправляется на HTTPS, и там 400.
-
-### Следующий шаг
-
-Проверить `$ssl_redirect = true` в nginx server block для нашего хоста:
- Если да — nginx делает redirect HTTP→HTTPS
- Добавить аннотацию `nginx.ingress.kubernetes.io/ssl-redirect: "false"` или тестировать через HTTPS
-
-### Правило (новое)
-
-Если файл `doc/thinking/ГГГГ-ММ-ДД.md` стал большим — создавать `ГГГГ-ММ-ДД-02.md`, `ГГГГ-ММ-ДД-03.md` и т.д.
-
---
-
-## Задача: Анализ безопасности MQTT multitenancy
-
-### Что исследовал
-
-Пользователь спросил об угрозах межтенантного проникновения.
-
-Изучил:
-1. `emqx.conf` в поде — `authorization { no_match = allow }` — после CONNECT всё разрешено
-2. `internal/api/handler/iot_device_handler.go` — `MQTTAuth` возвращает только `{"result":"allow"}` без ACL rules
-
-### Вывод
-
-**Auth (CONNECT) защищён:**
- HTTP auth endpoint проверяет namespace+deviceId+password (constant-time compare)
- enabled=true проверяется
- Secret изолирован по namespace
-
-**ACL на pub/sub НЕТ:**
- `no_match = allow` — аутентифицированный клиент может SUBSCRIBE на любой топик
- EMQX HTTP auth plugin поддерживает возврат ACL rules в ответе на auth
- Формат ответа: `{"result":"allow","acl":[{"permission":"allow","action":"all","topic":"sless/ns/+"}]}`
- Текущий `mqttAuthResponse` содержит только `Result string` — ACL поле отсутствует
-
-### Риски по приоритету
-
-1. **Критично**: User A может SUBSCRIBE `sless/#` и читать все IoT данные всех пользователей
-2. **Средне**: Нет rate limit на MQTT — один клиент может flood брокер
-3. **Низко**: Нет TLS на 8083 (WebSocket без шифрования) — данные видны в сети
-
-### План фикса
-
-Добавить в `mqttAuthResponse` поле `ACL []aclRule` и возвращать из `MQTTAuth`:
-```json
-{
-  "result": "allow",
-  "acl": [
-    {"permission": "allow", "action": "publish", "topic": "sless/{ns}/{deviceId}"},
-    {"permission": "allow", "action": "subscribe", "topic": "sless/{ns}/{deviceId}"},
-    {"permission": "deny", "action": "all", "topic": "#"}
-  ]
-}
-```
-
-Ждём подтверждения от пользователя перед реализацией.
-
---
-
-## Архитектурная дискуссия — IoT телеметрия и хранение данных
-
-### Контекст разговора
-
-Пользователь задал вопрос: "куда пишутся данные с IoT датчиков?"
-
-Выяснилось что сейчас данные теряются — function pod получает событие но никуда не сохраняет. Это нормально для serverless (пользователь сам решает), но для IoT платформы нужно автоматическое хранение.
-
-### Анализ сценариев использования
-
-Реалистичные клиенты для Nubes (облачный провайдер СНГ, малый/средний бизнес):
-1. Мониторинг объектов (склады, серверные, торговые точки) — температура, влажность, протечка
-2. Умные счётчики / ЖКХ — снятие показаний без выезда
-3. Небольшое производство / агро — теплицы, мини-заводы
-
-Общий паттерн для всех: датчик → данные в БД → алерт если порог → график
-
-### Решение по хранению данных
-
-**Вопрос**: один большой Postgres или отдельный на каждого?
-**Ответ**: один Postgres инстанс, но отдельная DATABASE на каждого tenant.
-
-Причины:
- Вариант со одной таблицей + tenant_id — изоляция программная, ошибка в коде = утечка
- Отдельная DATABASE — физическая изоляция, разные connection string, разные пароли
- Клиент B не может подключиться к DATABASE клиента A даже при баге в коде платформы
-
-Структура:
-```
-Postgres инстанс
-├── sless_platform DB  — системные таблицы (tenants, invocations)
-├── tenant_abc DB      — только данные клиента A
-└── tenant_def DB      — только данные клиента B
-```
-
-### Решение по доступу клиента
-
-**Вопрос**: давать клиенту прямой доступ к Postgres?
-**Ответ**: нет. Только через REST API платформы.
-
-Причины:
- Postgres внутри кластера, снаружи не торчит (security)
- Единый endpoint `iot.kube5s.ru`
- Легко добавить rate limit, биллинг, кеш
- Клиент не зависит от деталей реализации хранилища
-
-API:
-```
-GET /v1/namespaces/{ns}/iot/telemetry?device=X&from=T&to=T
-GET /v1/namespaces/{ns}/iot/devices/{id}/last
-```
-
-### Решение по schema.sql
-
-Клиент может положить `schema.sql` рядом с функцией. При деплое платформа выполняет его в БД tenant'а.
-Это даёт низкий порог входа — клиент не шарит в Python, но может написать SQL по шаблону.
-
-### Ключевое архитектурное решение — разделение операторов
-
-**Решение**: sless-operator и iot-operator — ОТДЕЛЬНЫЕ компоненты.
-Пока в одном кластере, но сделать так чтобы могли быть в разных.
-
-**Namespace layout:**
-```
-namespace: sless          — платформа sless (operator, event-dispatcher, RabbitMQ, Postgres invocations)
-namespace: sless-{hash}   — tenant функции (function pods)
-namespace: iot            — платформа IoT (iot-operator, EMQX, Postgres telemetry)
-namespace: iot-{hash}     — tenant IoT (IoTDevice CRDs)
-```
-
-**Связь**:
- Общий идентификатор tenant: `{hash}` одинаковый в обоих namespace
- MQTT событие → RabbitMQ в sless → function pod в sless-{hash}
- IoT operator НЕ импортирует пакеты sless-operator (loose coupling)
- Общение только через k8s API и RabbitMQ
-
-**Postgres**:
- sless имеет свой Postgres (invocations)
- iot имеет свой Postgres (telemetry per tenant)
- Разные StatefulSet, разные PVC
-
-### Что делает пользователь
-
-Клиент:
-1. Подключает устройство → данные автоматически пишутся в его `iot_telemetry`
-2. Пишет функцию которая реагирует на события
-3. Функция получает `DB_DSN` в env var (автоматически из Secret)
-4. Может делать SELECT/INSERT в свою БД через обычный SQL в коде функции
-5. Может читать телеметрию через REST API
-
-### Plan — следующие шаги (этап IoT Postgres)
-
-1. Поднять Postgres StatefulSet в namespace `iot`
-2. В iot-operator при создании IoTDevice namespace → `CREATE USER`, `CREATE DATABASE`, `CREATE TABLE iot_telemetry`, `CREATE TABLE iot_devices`
-3. Credentials → k8s Secret `iot-tenant-{ns}-pg`
-4. В iot-mqtt-bridge при получении MQTT сообщения → INSERT в tenant БД
-5. REST API endpoint для чтения телеметрии
-6. При деплое function → прокинуть `DB_DSN` в env var из Secret
-7. При деплое function → если есть `schema.sql` → выполнить в tenant БД
-
-### Технические решения
-
- Postgres: `postgres:16-alpine` StatefulSet с PVC 10Gi в namespace `iot`
- Connection pool: pgxpool (pgx v5) per-tenant, lazy init, max 5 conn per tenant
- Таблица telemetry: `(id bigserial, device_id text, ts timestamptz default now(), payload jsonb)`
- Индекс: `(device_id, ts DESC)` для быстрых запросов по устройству за период
- Retention: пока без TTL, добавить позже через pg_partman или cron job
-
-
---
-## 2026-04-04 — IoT Console UI: план и реализация
-
-**Агент**: GitHub Copilot (Claude Sonnet 4.6)
-
-### Постановка задачи
-
-Пользователь сформулировал: нужен UI для управления IoT устройствами.
-Причина: не все пользователи работают через Terraform/API напрямую.
-Нужно: создать устройство, получить credentials, прошить в устройство, проверить отправку данных.
-
-### Ключевое решение: эмулятор устройства в браузере
-
-MQTT WebSocket уже работает: `ws://iot.kube5s.ru:80/mqtt`.
-Браузер через mqtt.js (CDN) может подключиться как устройство напрямую.
-Это значит: эмулятор — это не "симуляция", а реальная публикация MQTT сообщений.
-
-Когда у клиента ещё нет физического устройства — он тестирует через эмулятор.
-Это закрывает весь цикл без необходимости устанавливать MQTT-клиент.
-
-### Архитектурные решения UI
-
-**Стек**: ванильный HTML/CSS/JS + mqtt.js (CDN). Никаких фреймворков.
-**Где хранить**: встраиваем в бинарник оператора через `go:embed`.
-  - Файл: `internal/api/ui/iot-console.html`
-  - Маршрут: `GET /console`
-
-**Где доступен**: `http://iot.kube5s.ru/console`
-  - Ingress добавляем path `/console` → `sless-operator:9090`
-
-**Почему не `https://sless.kube5s.ru/console`:**
-  - UI на HTTPS + MQTT WS без TLS = mixed content, браузер блокирует
-  - UI на HTTP + MQTT WS = нет mixed content, всё работает
-  - HTTP → HTTPS API вызовы разрешены (это не mixed content)
-  - Нужен только CORS на API стороне
-
-**CORS**: заголовки `Access-Control-Allow-Origin: http://iot.kube5s.ru` + OPTIONS preflight
-
-### Страницы
-
-1. Вход: API адрес + MQTT брокер + namespace + токен → localStorage
-2. Список устройств: таблица, создать, удалить
-3. Устройство (3 вкладки):
-   - Credentials: username, password скрыт, топик, инструкция
-   - Эмулятор: подключиться → JSON payload → send / авто
-   - Телеметрия: "скоро"
-
-### Следующие шаги после UI
-
-1. Postgres StatefulSet в namespace `iot`
-2. INSERT в iot_telemetry из mqtt-bridge
-3. REST API для чтения телеметрии
-4. Заполнить вкладку "Телеметрия" в UI
-
---
-# Агент: GitHub Copilot (Claude Sonnet 4.6) — продолжение сессии 2026-04-04
-
-## Исправления и улучшения IoT Console UI (v0.1.53 → v0.1.58)
-
-### Проблема 1: `crypto.subtle.digest` — Cannot read properties of undefined
-
-**Симптом:** Пользователь вставил токен, получил ошибку "Cannot read properties of undefined (reading 'digest')".
-
-**Анализ:** `crypto.subtle` доступен ТОЛЬКО на HTTPS-страницах (Secure Context). Консоль раздавалась по HTTP (`http://iot.kube5s.ru/console`). На HTTP `crypto.subtle === undefined`.
-
-**Решение:** Перевести консоль на HTTPS — это устранит корень проблемы и заодно уберёт необходимость в pure-JS SHA256. Попытка написать pure-JS SHA256 была правильной как fallback, но правильнее — исправить инфраструктуру.
-
-**Действия:**
-1. `emqx-ws-ingress.yaml`: добавлена TLS-секция + `cert-manager.io/cluster-issuer: letsencrypt-prod`, `ssl-redirect: "true"`, `secretName: iot-kube5s-ru-tls`
-2. `router.go`: CORS `Allow-Origin`: `http://` → `https://iot.kube5s.ru`
-3. `iot-console.html`: дефолт MQTT брокера `ws://` → `wss://`
-4. cert-manager автоматически выпустил сертификат Let's Encrypt (READY: True за ~34 сек)
-5. Собрали v0.1.54, задеплоили
-
-**Косяк при apply:** `kubectl apply` взял старый Ingress из кэша (только путь `/mqtt`, без `/console`). Пришлось использовать `kubectl replace` вместо `apply`.
-
-**Итог:** `https://iot.kube5s.ru/console` → 200, TLS v1.3, `CN=iot.kube5s.ru`, Let's Encrypt R13. `crypto.subtle` заработал.
-
---
-
-### Проблема 2: 404 после перехода на HTTPS (v0.1.54)
-
-**Симптом:** После `kubectl apply` + rollout — curl возвращал 404.
-
-**Анализ:** Запрос доходил до пода (видно в логах), но оператор отвечал 404. Значит маршрут `/console` не регистрировался. Проверили: файл `iot-console.html` существует на диске, `go:embed` прописан, маршрут в `router.go` есть. **Причина:** первый `docker build` взял Go-слои из кэша Docker — старый бинарь без `/console` маршрута.
-
-**Решение:** Пересборка с `--no-cache`. После пуша нового диджеста и `kubectl rollout restart` — заработало.
-
---
-
-### Улучшение: убрать поля API/MQTT из формы входа (v0.1.56)
-
-**Анализ:** Пользователь справедливо спросил "ЗАЧЕМ юзеру это вводить?" — адреса `https://sless.kube5s.ru` и `wss://iot.kube5s.ru/mqtt` фиксированы для данного деплоя. Пользователь не должен их трогать.
-
-**Решение:** Удалены `<input id="f-api">` и `<input id="f-mqtt">` из формы. В `doLogin()` адреса берутся из хардкода, не из DOM. Форма стала: только поле токена + кнопка "Войти".
-
-**Параллельно:** Добавлен блок `<details class="help-block">` внизу страницы устройства — 5 шагов инструкции: Credentials → формат JSON → Эмулятор → Авто → Телеметрия (скоро).
-
---
-
-### Ребрендинг: Nubes brand design (v0.1.57)
-
-**Задача:** "Оформи чтобы строго, чётко — как на terra.k8c.ru".
-
-**Исследование:**
- Скачал SVG логотипа: `https://terra.k8c.ru/docs/nubes/nubes/2.0.2/30_registry/assets/logo.svg`
- Логотип залит `#001C34` — это основной Nubes Navy цвет
- Сайт nubes.ru использует тёмно-синий (#001C34) как бренд-прайм
-
-**Палитра:**
-| Переменная     | Цвет       | Назначение                   |
-|----------------|------------|------------------------------|
-| brand primary  | `#001C34`  | Navbar, карточки, логотип    |
-| page bg        | `#001120`  | Фон страницы                 |
-| card surface   | `#001929`  | Карточки .card               |
-| borders        | `#0b2d50`  | Границы, разделители         |
-| accent         | `#1a7fd4`  | Кнопки, табы, ссылки         |
-| text primary   | `#e2ecf6`  | Основной текст               |
-| text secondary | `#6b8eaa`  | Метки, подписи               |
-| text muted     | `#2d5070`  | Отключённые, подсказки       |
-
-**Изменения в CSS:**
- Navbar: `background: #001C34`, логотип SVG с `filter: brightness(0) invert(1)` (белый)
- Badges: прямоугольные (`border-radius: 4px`), UPPERCASE, компактные
- Кнопки: `font-weight: 600`, `letter-spacing: 0.02em`
- Таблицы: заголовки `color: #2d5070` — строгие, тихие
- `.help-num`: квадратные (4px), не круглые
-
-**Форма входа:** логотип SVG (инвертированный) вместо `⚡`, подпись `IoT Console` uppercase вместо названия по-русски.
-
---
-
-### Favicon (v0.1.58)
-
-**Задача:** Иконка вкладки браузера — как у Nubes docs.
-
-**Исследование:** `curl https://terra.k8c.ru/docs/nubes/nubes/2.0.2/` → `<link rel="icon" href="30_registry/assets/favicon.png">`
-
-**URL:** `https://terra.k8c.ru/docs/nubes/nubes/2.0.2/30_registry/assets/favicon.png`
-
-**Решение:** Добавлена одна строка в `<head>`:
-```html
-<link rel="icon" href="https://terra.k8c.ru/docs/nubes/nubes/2.0.2/30_registry/assets/favicon.png">
-```
-
---
-
-## Итоговые версии
-
-| Версия  | Изменение                                       | Коммит   |
-|---------|-------------------------------------------------|----------|
-| v0.1.54 | TLS на iot.kube5s.ru, wss://, CORS https       | fb6f9d4  |
-| v0.1.55 | Help-блок на странице устройства                | e547871  |
-| v0.1.56 | Убраны поля API/MQTT из формы входа             | e547871  |
-| v0.1.57 | Nubes brand rebrand — палитра, логотип          | 0400f97  |
-| v0.1.58 | Favicon Nubes                                   | 93e87a3  |
-
-## Текущее состояние
-
- ✅ `https://iot.kube5s.ru/console` — работает, TLS, Nubes-дизайн, favicon
- ✅ MQTT: `wss://iot.kube5s.ru/mqtt`
- ✅ `crypto.subtle` работает (HTTPS)
- ✅ Форма входа: только токен
- ✅ Namespace скрыт от пользователя
- ❌ Телеметрия — заглушка, бэкенд не написан
-
-## Следующий шаг
-
-Бэкенд телеметрии:
-1. Postgres StatefulSet в namespace `iot`
-2. Tenant provisioning при создании IoTDevice
-3. INSERT в mqtt-bridge
-4. REST API чтения
-5. Вкладка Телеметрия в UI
@@ -1,681 +0,0 @@
-# Лог мышления — 2026-04-04
-
-## Агент: GitHub Copilot (Claude Opus 4.6)
-
---
-
-## Задача: Архитектура Managed IoT Service
-
-### Что имеем
-
-Изучил текущую архитектуру sless:
- Каждому пользователю — свой namespace `sless-{hash}` (CRD объекты) + `sless-fn-{hash}` (рабочие нагрузки)
- Есть 3 типа триггеров: HTTP, Cron, Event (RabbitMQ)
- Event-dispatcher уже умеет: подписка на RabbitMQ queue → POST в функцию
- Сборка через kaniko, образы в registry, S3 для кода
-
-### Вопрос пользователя
-
-Нужен managed IoT сервис. Вопрос: каждому юзеру свой брокер (Rabbit/Kafka), свой Postgres?
-
-### Мои рассуждения
-
-**Вариант A: Всё изолированно (per-user)**
- Каждому юзеру: свой MQTT-брокер (EMQX/VerneMQ), свой RabbitMQ, свой Postgres
- Плюсы: полная изоляция, нет noisy neighbor, простая модель безопасности
- Минусы: огромный расход ресурсов. 100 юзеров = 100 MQTT-брокеров + 100 Postgres + 100 RabbitMQ. Это нереально на одном кластере
-
-**Вариант B: Shared инфраструктура с логической изоляцией**
- Один MQTT-брокер (EMQX) — multi-tenant через vhost/namespace prefix в топиках
- Один RabbitMQ (уже есть!) — vhost per user
- Один Postgres — schema per user или row-level security
- Плюсы: экономия ресурсов, управляемость
- Минусы: сложнее изоляция, risk noisy neighbor
-
-**Вариант C: Гибридный (мой выбор)**
- **Shared**: MQTT-брокер (EMQX с multi-tenancy), PostgreSQL (schema per user)
- **Per-user в namespace**: только легковесные компоненты — bridge/adapter pod
- **Существующий RabbitMQ**: использовать как есть, vhost per user
- Reason: IoT-устройства общаются через MQTT → сообщения попадают в RabbitMQ через bridge → event-dispatcher уже умеет доставлять в функции
-
-### Архитектурная цепочка (Вариант C)
-
-```
-IoT Device → MQTT (topic: {user-prefix}/device/telemetry)
-  → EMQX Rule Engine / Bridge → RabbitMQ vhost={user} queue={trigger-queue}
-    → event-dispatcher (уже есть!) → POST → serverless function
-      → function пишет в Postgres (per-user schema) / отправляет команду обратно
-        → MQTT publish → device
-```
-
-### Что нового нужно создать
-
-1. **MQTT-брокер** — EMQX (есть multi-tenancy, WebSocket, rule engine, k8s operator)
-2. **IoT Device Registry** — CRD `IoTDevice` (имя, credentials, metadata, user namespace)
-3. **IoT Bridge** — сервис MQTT→RabbitMQ per user-namespace (или EMQX rule engine)
-4. **Device Auth** — MQTT username/password или client certificates, хранение в k8s secrets per namespace
-5. **Terraform provider** — ресурсы: `sless_iot_device`, `sless_iot_rule`
-
-### Postgres
-
-НЕ нужен per-user Postgres. Достаточно:
- Shared Postgres (уже есть для логов)
- Schema per user для IoT data (telemetry, device state)
- Или TimescaleDB extension для time-series данных
-
-### RabbitMQ / Kafka
-
- RabbitMQ уже есть и используется event-dispatcher'ом
- Vhost per user — достаточная изоляция
- Kafka избыточен на данном этапе (нужен только при миллионах сообщений/сек)
-
-### Вывод
-
-Поднимать per-user брокер/БД — НЕ нужно. Нужна shared инфраструктура с логической изоляцией. Основная работа: EMQX + мост в RabbitMQ + device registry CRD.
-
---
-
-## Агент: GitHub Copilot (Claude Sonnet 4.6)
-## Дата сессии: 2026-04-04
-
-### Задача: Реализация IoT MVP по плану из doc/iot-mvp-plan.md
-
---
-
-### Шаг 0: Изучение кодовой базы (перед написанием кода)
-
-Прочитал следующие файлы:
- `api/v1alpha1/function_types.go` — паттерн написания CRD типов
- `api/v1alpha1/trigger_types.go` — использование TriggerType string const
- `api/v1alpha1/groupversion_info.go` — паттерн регистрации API group
- `controllers/function_controller.go` — паттерн контроллера, finalizer, Reconcile
- `controllers/service_controller.go` — второй контроллер для сравнения
- `internal/api/router.go` — регистрация маршрутов, auth middleware
- `main.go` — как регистрируются контроллеры, как подключается API
- `go.mod` — версии зависимостей (k8s v0.26.0, controller-runtime v0.14.1)
-
-#### Что понял
-
-**Go module**: `gitea-naeel.giteak8s.services.ngcloud.ru/naeel/sless`
-**API сервер**: gorilla/mux, auth через middleware на `/v1/` subrouter
-**Паттерн контроллера**: `r.Get → finalizer → business logic → r.Status().Update()`
-**Finalizer**: у function = `sless.kube5s.ru/finalizer`, у service = `sless.kube5s.ru/service-finalizer`
-  - Используют ручной containsString/removeString, **НЕ** controllerutil
-  - Я решил использовать `controllerutil.ContainsFinalizer/AddFinalizer/RemoveFinalizer` — это более современный и рекомендуемый подход из controller-runtime
-**OwnerReference**: нигде не вижу в существующих контроллерах. Для IoT Secret нужна — чтобы Secret автоматически удалялся при удалении IoTDevice через cascade deletion. Использую `controllerutil.SetControllerReference`.
-
-#### Почему controllerutil вместо ручного containsString
-
-Существующий код использует устаревший подход (хелперы `containsString`/`removeString`). `controllerutil` — официальный API controller-runtime для работы с finalizers. Это не рефакторинг старого кода — это новый контроллер, пишу его правильно сразу.
-
---
-
-### Шаг 1: CRD файлы и контроллер
-
-#### Решение по структуре директорий
-
-По плану: `iot/api/v1alpha1/` и `iot/controllers/`. Это отдельный package path от `api/v1alpha1`.
- IoT CRD package: `gitea-naeel.giteak8s.services.ngcloud.ru/naeel/sless/iot/api/v1alpha1`
- IoT контроллер package: `gitea-naeel.giteak8s.services.ngcloud.ru/naeel/sless/iot/controllers`
- Тот же go.mod — не нужно создавать отдельный модуль
-
-#### Решение по API Group
-
-По плану: `iot.kube5s.ru` — отдельная от `sless.kube5s.ru`.
-Причина: при выносе в отдельную репу CRD не будет конфликтовать. Принимаю.
-
-#### MQTTUsername формат
-
-По плану: `{namespace}_{deviceId}`.
-Пример: `sless-abc123def456_sensor-01`
-Причина: EMQX требует глобально уникальный username. Namespace даёт изоляцию.
-
-#### Secret name
-
-По плану: `iot-{deviceId}`.
-**Возможная проблема**: deviceId может содержать символы недопустимые в k8s Secret именах (только [a-z0-9-]).
-**Решение**: в kubebuilder validation на DeviceID добавить regex `[a-z0-9-]+`. Если deviceId уже проходит валидацию — проблемы нет.
-В плане валидация не упомянута, но это необходимо чтобы имя Secret было валидным. Добавлю `+kubebuilder:validation:Pattern`.
-
-#### Генерация пароля
-
-32 байта через `crypto/rand.Read` → `hex.EncodeToString` = 64 символа.
-Это достаточно энтропии (256 бит).
-
-#### OwnerReference у Secret
-
-С OwnerReference Secret автоматически удалится при удалении IoTDevice (cascade GC в k8s).
-Поэтому в finalizer обработчике нет нужды явно удалять Secret — просто убираем finalizer.
-
-**Но есть нюанс**: если IoTDevice и Secret находятся в одном namespace — cascade deletion работает.
-В нашем случае оба в `sless-{hash}` — OK.
-
-#### Обработка статуса
-
-`r.Status().Update()` — только subresource. Не трогает `spec` или `metadata`. Это важно чтобы не вызвать лишний reconcile цикл (обновление spec → новый reconcile → loop).
-
-#### Disabled устройство
-
-Если `spec.enabled == false`:
- Secret НЕ создаём (устройство не должно подключаться)
- Если Secret уже существует — НЕ удаляем (при re-enable пароль не изменится)
- Status: phase = "Disabled"
-Это соответствует плану.
-
-**Стоп — перечитал план**: "Установить status.phase = 'Disabled' — НЕ удалять Secret". Значит если disabled — просто обновить статус, Secret остаётся. Принимаю.
-
---
-
-### Что создаю (Этап 1)
-
-1. `iot/api/v1alpha1/device_types.go` — CRD IoTDevice
-2. `iot/api/v1alpha1/groupversion_info.go` — API group iot.kube5s.ru/v1alpha1
-3. `iot/controllers/iotdevice_controller.go` — контроллер
-4. `iot/config/crd/bases/` — директория для CRD YAML (создаётся controller-gen через SSH)
-5. Обновление `main.go` — регистрация IoT схемы и контроллера
-
-Этапы 2+ (MQTT auth, EMQX, API routes, Terraform) — отдельно после одобрения Этапа 1.
-
---
-
-### Этап 2-7: план перед реализацией
-
-#### API port
-Из `deployments/k8s/operator.yaml`: `API_PORT: "9090"`, сервис `sless-operator.sless.svc:9090`.
-RabbitMQ: `amqp://sless:sless123@rabbitmq.sless.svc.cluster.local:5672/`
-
-#### EMQX версия — проблема
-В плане указан `emqx/emqx:5.5.1`. Изучил вопрос:
- **EMQX 5.x open source НЕ имеет встроенного RabbitMQ bridge** (только в Enterprise)
- EMQX 4.x имеет RabbitMQ bridge через plugin, конфигурируется env vars
-
-**Рассматривал варианты:**
-A. EMQX 4.4 — встроенный bridge, но env vars другого формата чем в плане
-B. EMQX 5.x + HTTP Webhook rule → наш bridge HTTP сервер
-C. EMQX 5.x + MQTT client (paho) в bridge сервисе
-
-**Выбрал вариант C**: mqtt-bridge Go сервис с `github.com/eclipse/paho.mqtt.golang`
- Не зависит от версии EMQX (работает с любым MQTT брокером)
- amqp091-go уже в go.mod
- paho.mqtt.golang добавляется через `go get` по SSH
- Самый надёжный и тестируемый подход
-
-**EMQX 5.5.1**: используем только для HTTP auth (через emqx.conf HOCON).
-Bridge service подключается к EMQX как обычный MQTT клиент.
-
-#### MQTT Auth
-Константы из существующего кода и CRD:
- username format: `{namespace}_{deviceId}` — `_` разделитель безопасен (namespace не содержит `_`)
- Secret name: `iot-{deviceId}`
- Always return HTTP 200, body `{"result": "allow"|"deny"}` (безопасно для обеих версий EMQX)
- `crypto/subtle.ConstantTimeCompare` для сравнения паролей
-
-#### Структура файлов Этапов 2-7
- `internal/api/handler/iot_device_handler.go` — MQTT auth + IoT CRUD handlers
- `internal/api/router.go` — добавить IoT routes
- `deployments/k8s/emqx.yaml` — EMQX deployment c emqx.conf ConfigMap (только HTTP auth)
- `iot/cmd/mqtt-bridge/main.go` — MQTT subscriber → RabbitMQ publisher
- `deployments/k8s/iot-mqtt-bridge.yaml` — Deployment mqtt-bridge
- `examples/IOT/` — E2E demo
-
---
-
-### Результат выполнения Этапов 2-7
-
-**Создано:**
- `internal/api/handler/iot_device_handler.go` — MQTT auth + IoT CRUD handlers
- `internal/api/router.go` — IoT routes + `/internal/mqtt/auth`
- `deployments/k8s/emqx.yaml` — EMQX 5.5.1 deployment с emqx.conf (HTTP auth)
- `iot/cmd/mqtt-bridge/main.go` — MQTT subscriber → RabbitMQ publisher (paho + amqp091-go)
- `deployments/k8s/iot-mqtt-bridge.yaml` — Deployment mqtt-bridge
- `examples/IOT/` — E2E demo (main.tf, handler.py, README.md)
-
-**go.mod**: добавлен `github.com/eclipse/paho.mqtt.golang v1.5.1`
-
-**go build ./...** — ошибок нет.
-
-**Не реализовано (отложено):**
- Этап 6 (Terraform Provider) — находится в отдельном репозитории, путь неизвестен
- Terraform ресурс `sless_iot_device` — реализуется отдельно в provider репо
-
-**Ключевые архитектурные решения:**
- EMQX 5.5.1 (как в плане) — HTTP auth через emqx.conf HOCON
- mqtt-bridge использует paho.mqtt.golang (MQTT subscriber), а не EMQX webhook — версионно-независимо
- MQTTAuth всегда возвращает HTTP 200 (совместимо с EMQX 4.x и 5.x)
- `crypto/subtle.ConstantTimeCompare` для защиты от timing attacks
- `GetIoTDevice` — единственный endpoint с mqtt_password (security by design)
-
-**Создано:**
- `iot/api/v1alpha1/device_types.go` — CRD IoTDevice с IoTDevicePhase константами
- `iot/api/v1alpha1/groupversion_info.go` — API group `iot.kube5s.ru/v1alpha1`
- `iot/api/v1alpha1/zz_generated.deepcopy.go` — сгенерирован controller-gen
- `iot/config/crd/bases/iot.kube5s.ru_iotdevices.yaml` — CRD манифест
- `iot/controllers/iotdevice_controller.go` — контроллер с полным Reconcile loop
- `main.go` — добавлена регистрация IoT схемы и контроллера
-
-**Проверка:** `go build ./...` — ошибок нет.
-
-**Отклонения от плана (с обоснованием):**
- Добавлен `+kubebuilder:validation:Pattern` на `DeviceID` — необходимо чтобы имя Secret `iot-{deviceId}` было валидным k8s именем. В плане не указано, но без валидации контроллер может сломаться.
- Использован `controllerutil.ContainsFinalizer/AddFinalizer/RemoveFinalizer` вместо ручных хелперов — более современный подход из controller-runtime. Старый код не трогал.
- Добавлена константа `IoTDevicePhase` (типизированный string) вместо plain string в плане — для type-safety и читаемости.
-
---
-
-## Задача: Решения по архитектуре IoT MVP
-
-### Вопрос 1: Репозиторий — та же или новая?
-
-**Анализирую связи:**
- IoT генерирует события → RabbitMQ → event-dispatcher → serverless функции
- Связь между IoT и sless = на уровне message bus (RabbitMQ), НЕ на уровне кода
- Общее: концепция user namespace (sless-{hash}), аутентификация (JWT→namespace)
- Разное: домен (устройства vs функции), протоколы (MQTT vs HTTP), CRD-типы
-
-**Вариант A: Та же репа**
- Плюс: общий go.mod, общие утилиты namespace, быстрый старт
- Плюс: один оператор — проще деплоить для демо
- Минус: два домена в одной репе — запутает
- Минус: разные циклы релизов в будущем
-
-**Вариант B: Новая репа**
- Плюс: чистое разделение, независимые релизы
- Минус: дублирование namespace-логики или общая библиотека
- Минус: overhead для демо слишком большой
-
-**Вариант C (мой выбор): Та же репа, изолированная структура**
- Весь IoT-код в директории `iot/` на верхнем уровне
- Свои контроллеры: `iot/controllers/`
- Свои CRD: `iot/api/v1alpha1/`
- Свой деплоймент (отдельный binary или часть того же оператора)
- Легко вынести в отдельную репу позже — просто перемещаем `iot/`
- Для демо: контроллеры IoT встраиваются в тот же operator binary (один pod)
-
-**Reason**: связь IoT↔sless через RabbitMQ — слабая. Код не зависит друг от друга. Но для демо удобнее держать вместе. Структура `iot/` позволяет легко разделить.
-
-### Вопрос 2: Terraform provider — расширять или новый?
-
-**Факты:**
- Текущий провайдер: `sless` (terraform-provider-sless)
- Ресурсы: sless_function, sless_trigger, sless_service
- Auth: JWT → namespace
-
-**Анализ:**
- Имя "sless" не подходит для IoT-ресурсов (`sless_iot_device` — странно)
- Но auth/namespace логика идентична
- Для демо: расширение существующего — быстрее всего
- Для прода: нужен единый провайдер `nubes` (бренд облака) с подресурсами, или отдельный `nubes-iot`
-
-**Мой выбор: расширить текущий для демо**
- Добавить `sless_iot_device`, `sless_iot_rule`
- Имя неидеальное, но для демо ОК
- Для прода: переименование в `nubes` — отдельная задача (breaking change)
- Альтернатива: сразу назвать новый провайдер `nubes-iot`, но это overhead для демо
-
-**Рекомендация пользователю**: решить позже, когда IoT станет полноценным сервисом. Для демо — расширяем sless.
-
-### Вопрос 3: Scope MVP — что включаем?
-
-**Полный IoT-сервис** (для справки):
-1. MQTT-брокер ✓ 
-2. Device Registry ✓
-3. Device Auth ✓
-4. Rules Engine (маршрутизация)
-5. Time-series storage (телеметрия)
-6. Device Shadow/Twin (состояние)
-7. Command Channel (cloud→device)
-8. Dashboard/мониторинг
-
-**MVP (демо с возможностью усложнения):**
-
-ДА, включаем:
-1. ✅ EMQX — деплой через YAML/Helm в кластер
-2. ✅ CRD `IoTDevice` — имя, namespace, credentials (username/password), metadata
-3. ✅ IoT-контроллер — reconcile IoTDevice → создаёт MQTT credentials в EMQX через HTTP API
-4. ✅ EMQX → RabbitMQ bridge — маршрутизация: MQTT topic → RabbitMQ queue
-5. ✅ Включение event-триггеров в sless API (снятие блокировки)
-6. ✅ Terraform: `sless_iot_device` (CRUD)
-7. ✅ E2E демо: device → MQTT → function вызывается
-
-НЕТ, откладываем:
- ❌ Device Shadow — усложнение, не нужно для демо
- ❌ Rules Engine — для демо хватит простой маршрутизации topic→queue
- ❌ Time-series storage — функция сама может писать в Postgres
- ❌ Command channel (cloud→device) — второй этап
- ❌ Client certificates — для демо username/password
- ❌ Dashboard — Grafana + метрики EMQX потом
-
-### Вопрос 4: Архитектура MVP — как именно работает
-
-**Цепочка данных:**
-```
-IoT Device
-  → MQTT connect (username=deviceId, password=deviceSecret)
-  → EMQX (topic: {namespace}/telemetry/{deviceId})
-    → EMQX Rule + Bridge → RabbitMQ (queue: iot.{namespace}.{topic-pattern})
-      → sless event-dispatcher (существующий) → POST body → serverless function
-        → function обрабатывает данные
-```
-
-**Аутентификация устройств:**
- EMQX HTTP Auth Backend → наш API: `POST /internal/mqtt/auth`
- Контроллер при создании IoTDevice → генерирует credentials → хранит в k8s Secret
- EMQX проверяет при MQTT CONNECT: запрос к нашему API → проверка credentials → ACL (device видит только свой namespace)
-
-**Почему EMQX HTTP Auth, а не встроенная БД:**
- При добавлении/удалении устройства не нужно перезагружать EMQX
- ACL динамический — привязан к namespace
- Возможность усложнения (certificates, OAuth) без изменения EMQX
-
-**Структура файлов (план):**
-```
-iot/
-  api/v1alpha1/
-    device_types.go          # CRD IoTDevice
-    groupversion_info.go
-    zz_generated.deepcopy.go
-  controllers/
-    device_controller.go     # Reconcile: создаёт credentials, Secret
-  internal/
-    emqx/
-      client.go              # HTTP-клиент к EMQX Management API
-    mqtt_auth/
-      handler.go             # HTTP Auth Backend для EMQX
-  deployments/
-    emqx.yaml                # Деплой EMQX в кластер
-```
-
-**Что НЕ нужно создавать с нуля:**
- RabbitMQ — есть
- Event-dispatcher — есть (только включить event triggers)
- Namespace-логика — есть (переиспользуем)
- API-сервер (JWT auth, routing) — есть, добавляем IoT-эндпоинты
-
---
-
-## Вопрос: RabbitMQ vs Kafka для IoT
-
-### Контекст
- RabbitMQ уже развёрнут, event-dispatcher написан под AMQP
- Пользователь хочет "с прицелом на будущее, без переделок"
- IoT = потенциально тысячи устройств, миллионы сообщений
-
-### Сравнение для IoT
-
-| Критерий | RabbitMQ | Kafka |
-|----------|----------|-------|
-| Модель | Push (broker → consumer) | Pull (consumer → offset) |
-| Хранение | Сообщение удаляется после ack | Лог хранится N дней (replay!) |
-| Масштаб | до ~50K msg/sec (один node) | миллионы msg/sec |
-| Multi-consumer | нет (сообщение потреблено = удалено) | да (разные consumer groups) |
-| IoT replay | невозможен | ключевая фича |
-| Операционные затраты | проще | сложнее (KRaft, partitions) |
-| Per-user изоляция | vhost | topic prefix, ACL |
-| Уже есть | да | нет |
-
-### Для IoT Kafka объективно лучше потому что:
-
-1. **Replay** — устройство отправило данные, функция упала → с Kafka можно перечитать. С RabbitMQ — данные потеряны (nack+requeue — не то же самое)
-2. **Multi-consumer** — одни и те же данные от датчика читают: функция-алерт, функция-аналитика, Trino (!) для запросов. С RabbitMQ нужны exchange fanout + N очередей (костыль)
-3. **Time-series природа** — IoT телеметрия = append-only лог. Kafka создан именно для этого
-4. **Масштаб** — 1000 устройств × 1 msg/sec = 1000 msg/sec (RabbitMQ справится). 100K устройств × 10 msg/sec = 1M msg/sec (RabbitMQ не справится)
-5. **Trino** — Kafka connector для Trino → SQL-запросы по потоку данных в реальном времени. С RabbitMQ этого нет
-
-### НО: event-dispatcher сейчас написан под AMQP
-
-Переход = переписать event-dispatcher. Это ~300 строк кода. Не страшно.
-
-### Мой вывод
-
-Для IoT — Kafka. Для существующих serverless event-триггеров — RabbitMQ остаётся (менять рабочее не нужно).
-
-Два брокера — нормально:
- **RabbitMQ** — существующие event-триггеры sless (task queue: одно сообщение → одна функция)
- **Kafka** — IoT data pipeline (stream: данные хранятся, читаются многими)
-
-Это разные паттерны использования. Не нужно одним инструментом решать обе задачи.
-
---
-
-## Вопрос: может перевести sless тоже на Kafka — пока не обросли?
-
-### Думаю вслух
-
-Пользователь прав — переделывать потом больнее. Сейчас event-dispatcher = ~300 строк, event-триггеры ещё даже не включены в API. Идеальный момент для смены.
-
-### Для sless event-триггеров: что именно нужно?
-
-Паттерн: сообщение пришло → вызвать ОДНУ функцию → подтвердить/повторить.
-
-| Нужно для sless | RabbitMQ | Kafka |
-|-----------------|----------|-------|
-| Доставка 1 сообщение → 1 функция | нативно (queue) | consumer group (работает) |
-| Retry при ошибке | nack+requeue / dead letter — нативно | нужна логика retry-topic (код) |
-| Dead letter queue | встроен | нужен отдельный topic + код |
-| Приоритеты сообщений | да | нет |
-| Задержка доставки (delay) | плагин, просто | нет нативно |
-
-RabbitMQ для task queue **объективно удобнее**. Kafka для этого работает, но требует больше кода.
-
-### НО: два брокера в проде — это боль
-
- Два кластера мониторить
- Два набора алертов
- Два набора бэкапов
- Две точки отказа
- Двойное потребление ресурсов
-
-### Варианты
-
-**Вариант A: Два брокера (RabbitMQ для sless, Kafka для IoT)**
- Плюс: каждый инструмент для своей задачи
- Минус: операционная сложность × 2
-
-**Вариант B: Kafka для всего**
- Плюс: один брокер, одна инфраструктура
- Плюс: sless event-dispatcher переписать СЕЙЧАС — пока маленький
- Минус: retry/DLQ для sless придётся писать руками (~50 строк)
- Минус: Kafka тяжелее (3 ноды KRaft минимум для прода)
-
-**Вариант C: Redpanda вместо Kafka**
- Kafka-совместимый API, но single-binary, легче в ops
- Но менее зрелый, меньше community
-
-### Мой вывод
-
-**Kafka для всего.** Причины:
-1. Event-триггеры в sless ещё не запущены — переписать сейчас = 0 стоимости миграции
-2. Один брокер вместо двух — проще эксплуатация
-3. Retry через retry-topic — стандартный паттерн, ~50 строк кода
-4. Kafka для sless event-триггеров работает нормально (consumer group, offset commit = тот же ack)
-5. С прицелом: если sless и IoT оба на Kafka — проще интеграция (IoT event → sless function, один bus)
-
---
-
-## Контраргумент: single point of failure
-
-### Пользователь прав
-
-Если Kafka — единственный брокер и он падает → **оба сервиса мертвы** (sless event-triggers + IoT). Blast radius = вся платформа.
-
-А если два брокера:
- Kafka упал → IoT не работает, но sless event-триггеры живы (RabbitMQ)
- RabbitMQ упал → IoT работает, sless event-триггеры лежат
- Полный outage = нужно чтобы упали ОБА одновременно (маловероятно)
-
-### Пересмотр решения
-
-Это классический trade-off: операционная простота vs отказоустойчивость.
-
-Для managed service платформы — **отказоустойчивость важнее**. Клиент платит за uptime.
-
-### Финальное решение: ДВА брокера
-
- **RabbitMQ** → sless event-триггеры (уже написан, проще для task queue, независимый)
- **Kafka** → IoT pipeline (replay, multi-consumer, масштаб)
- Изоляция fault domains: падение одного не убивает другой сервис
-
-Операционная сложность двух брокеров — приемлемая цена за изоляцию.
-Мониторинг/алерты — решаемо (Prometheus + Grafana для обоих).
-
---
-
-## Реальность: кубер сломан, выходные, нет облачных сервисов
-
-### Ситуация
- Реалм пользователя не создаёт managed-сервисы (баг/инцидент)
- До понедельника никого нет (шабат/выходные)
- Kafka может оказаться в другом реалме, чем RabbitMQ
- Нужно работать с тем что есть СЕЙЧАС
-
-### Мои мысли
-
-**Вариант A: Делаем MVP на RabbitMQ (который есть)**
- Плюс: RabbitMQ уже работает, ничего разворачивать не нужно
- Плюс: event-dispatcher уже написан под AMQP
- Плюс: можно прямо сейчас начать IoT-часть (CRD, контроллер, EMQX, bridge)
- Плюс: demo будет работать к понедельнику
- Минус: потом нужна миграция EMQX→Kafka вместо EMQX→RabbitMQ bridge
- НО: мост MQTT→broker — это конфиг EMQX, а не наш код. Переключить EMQX bridge с RabbitMQ на Kafka = смена конфига, не переписывание
-
-**Вариант B: Поднять Kafka руками в кубере (Strimzi/Bitnami Helm)**
- Плюс: правильная архитектура с самого начала
- Минус: Kafka в k8s = тяжело (3 ноды KRaft, storage, сетевые проблемы)
- Минус: если реалм глючит — может и Kafka не развернуться
- Минус: потом всё равно мигрировать на managed
-
-**Вариант C (мой выбор): MVP на RabbitMQ сейчас, архитектура ready for Kafka**
-
-Суть: делаем IoT bridge через абстракцию, не привязываясь к конкретному брокеру.
-
-```
-EMQX → [bridge config] → RabbitMQ (сейчас)
-                        → Kafka (потом, смена конфига)
-
-IoT event consumer → [interface] → POST → function
-  сейчас: event-dispatcher (AMQP) уже есть
-  потом:  iot-consumer (Kafka) — отдельный сервис
-```
-
-Ключевое: НАША кодовая база НЕ зависит от выбора брокера.
- CRD IoTDevice — не зависит
- IoT контроллер — не зависит  
- MQTT auth — не зависит
- EMQX — bridge настраивается конфигом (RabbitMQ или Kafka)
- Единственная точка замены: consumer, который читает из брокера и POST в функцию
-
-### Что менять при переходе RabbitMQ → Kafka
-
-1. EMQX bridge config: `rabbitmq` → `kafka` (конфиг, не код)
-2. Consumer: отдельный iot-event-consumer вместо reuse event-dispatcher (~200 строк Go)
-3. Kafka deployment: managed или Strimzi
-
-Всё. Наш IoT-оператор, CRD, device auth — не меняются вообще.
-
---
-
-## Агент: GitHub Copilot (Claude Sonnet 4.6) — ДЕПЛОЙ IoT MVP
-
-### Задача от пользователя
-Запустить всё. Документировать мысли и инженерную часть подробно.
-
-### Анализ ситуации перед деплоем
-
-**Что есть в git (ветка Ioter, коммиты 716efaf + 1e53766 + b920dc5):**
- CRD IoTDevice (iot/config/crd/bases/iot.kube5s.ru_iotdevices.yaml) — готово, не задеплоено
- IoT controller + IoT API handlers — в бинаре `manager`, НО образ не пересобран (v0.1.49 = без IoT)
- EMQX YAML (deployments/k8s/emqx.yaml) — готово, не задеплоено
- iot-mqtt-bridge YAML (deployments/k8s/iot-mqtt-bridge.yaml) — готово, не задеплоено
- mqtt-bridge бинарь (iot/cmd/mqtt-bridge/main.go) — есть код, но НЕ в образе
-
-**Критические блокеры:**
-
-1. **Dockerfile не включает `iot/`** — оператор собирается без IoT кода. Нет, стоп.
-   После проверки: iot/api включается через импорты в main.go — Go компилятор тянет весь нужный код.
-   НО: Dockerfile копирует только `main.go api/ controllers/ internal/ migrations/`.
-   IoT код живёт в `iot/` — и этот каталог НЕ копируется в Dockerfile!
-   Значит: `go build -o manager main.go` внутри Docker упадёт — не найдёт пакеты `iot/api/v1alpha1`, `iot/controllers/`.
-
-2. **mqtt-bridge бинарь** — отдельная точка входа `iot/cmd/mqtt-bridge/main.go`.
-   В текущем Dockerfile собирается только `manager`. Нужно добавить сборку `iot-mqtt-bridge`.
-
-3. **iot-mqtt-bridge.yaml** использует образ оператора (`sless-operator:latest`) с командой `/iot-mqtt-bridge`.
-   Значит оба бинаря должны быть в одном образе. Это правильный подход — один образ, разные entrypoint.
-
-**Порядок действий (решение):**
-
-```
-1. Обновить Dockerfile:
-   - Добавить COPY iot/ iot/
-   - Добавить RUN go build -o iot-mqtt-bridge iot/cmd/mqtt-bridge/main.go
-   - Добавить COPY --from=builder /workspace/iot-mqtt-bridge .
-
-2. Обновить operator.yaml: тег v0.1.49 → v0.1.50
-
-3. SSH: docker build + push v0.1.50
-
-4. kubectl apply CRD IoTDevice (один раз, cluster-wide)
-
-5. kubectl apply EMQX (EMQX deployment + svc + configmap)
-
-6. kubectl apply operator v0.1.50 (подхватит IoT controller + IoT API)
-
-7. Bootstrap mqtt-bridge:
-   - Оператор должен быть живым (шаг 6)
-   - Создать IoTDevice "iot-bridge" через API → контроллер сгенерирует Secret в namespace sless-bridge
-   - Из Secret взять mqtt_username + mqtt_password
-   - kubectl create secret generic iot-bridge-credentials -n sless
-   - kubectl apply iot-mqtt-bridge.yaml
-
-8. Проверка end-to-end
-```
-
-**Риски и как их обходить:**
-
- `sless-bridge` namespace может не существовать → создать заранее через kubectl
- EMQX может быть не готов к моменту запуска bridge → bridge сам делает retry (в коде есть reconnect loop)
- IoT API требует JWT-токен → при bootstrap curl с токеном из sless-operator-secret
-
-**Почему один образ для operator + bridge:**
-Это не идеально с т.з. SRP, но практично:
- Не нужен отдельный CI pipeline
- Не нужен отдельный registry repo
- Bridge — простой процесс (~100 строк Go), не нагружает образ
- В будущем можно разделить, порог изменений низкий
-
-**Итог по мышлению:** Plan is solid. Начинаю выполнение.
-
-### Проблемы, найденные при выполнении (до → решение)
-
-**Проблема 1 — RBAC не настроен для iot.kube5s.ru:**
- Попытка создать IoTDevice через API → 403 Forbidden
- `sless-operator` ServiceAccount не имел прав на `iotdevices.iot.kube5s.ru`
- Причина: CRD для IoT — новая API-группа, в rbac.yaml её не было
- Решение: добавил в ClusterRole правила на `iot.kube5s.ru` (get/list/watch/create/update/patch/delete + status + finalizers)
- `kubectl apply -f rbac.yaml` → configured
- Вывод: при добавлении нового CRD API group ВСЕГДА нужно обновлять ClusterRole
-
-**Проблема 2 — EMQX 5.x требует обязательные поля node.cookie и node.data_dir:**
- EMQX CrashLoopBackOff с ошибкой: `required_field: node.cookie, node.data_dir`
- В нашем emqx.conf (HOCON) эти поля отсутствовали — думал что для single-node они необязательны
- На самом деле в EMQX 5.x они mandatory (в отличие от 4.x где были defaults)
- Решение: добавил `node {}` секцию: name=emqx@127.0.0.1, cookie=sless-emqx-cookie-mvp, data_dir=/opt/emqx/data
- kubectl apply обновил ConfigMap, rollout restart → EMQX поднялся
- Вывод: при обновлении ConfigMap Deployment не перезапускается автоматически — нужен `kubectl rollout restart`
-
-**Проблема 3 — kubectl logs берёт старый (crashing) pod:**
- deployment/emqx — логи шли со старого пода в CrashLoopBackOff
- Нужно указывать pod name явно для нового пода
- Это нормальное поведение kubectl — нет флага "новый pod"
-
-### Итоговый статус деплоя
-
-```
-emqx-6f9689fc99-4mbhr           1/1 Running ✅
-iot-mqtt-bridge-7d784d7d6b-n45fp 1/1 Running ✅ (3 restarts — reconnect loop до старта EMQX)
-sless-operator-579dd6dcd5-fk2n8  1/1 Running ✅
-```
-
-CRD применён: `iotdevices.iot.kube5s.ru created`
-IoTDevice iot-bridge создан: phase=Active, credentials в secret iot-iot-bridge
-Secret iot-bridge-credentials создан в namespace sless
@@ -1,178 +0,0 @@
-# Thinking Log — 2026-04-05
-## Агент: GitHub Copilot (Claude Opus 4.6)
-
---
-
-## Задача: написать подробный план реализации Telemetry Pipeline для Sonnet
-
-### Контекст
-Пользователь: "я не понял как этим пользоваться" — вкладка Телеметрия заглушка.
-Нужна полная цепочка: устройство -> данные в таблице.
-
-### Анализ — что уже есть
-IoT-компоненты реализованы на 85%: CRD, controller, EMQX, MQTT auth/ACL, mqtt-bridge, IoT Console.
-mqtt-bridge: MQTT -> RabbitMQ (для function triggers). Данные НЕ сохраняются.
-Postgres для invocations есть, для IoT телеметрии — нет.
-
-### Ключевые решения при написании плана
-1. Postgres сразу (пользователь настоял)
-2. Отдельный Postgres инстанс (iot-postgres), но в namespace sless
-3. DATABASE per tenant (изоляция)
-4. mqtt-bridge: INSERT параллельно с RabbitMQ publish
-5. REST API: GET /v1/.../iot/telemetry (только limit, без from/to)
-6. Эмулятор: рандом temp 18-28, humidity 40-80
-
-### Результат
-Записан подробный план в doc/iot-mvp-plan.md — 7 шагов с файлами, кодом и YAML.
-
---
-
-## GitHub Copilot (Claude Sonnet 4.6)
-
-## Задача 1 — Задеплоить фикс switchTab (продолжение прошлой сессии)
-
-### Контекст
-Предыдущая сессия: autoTimer убирался из switchTab, но не был задеплоен.
-Файл `internal/api/ui/iot-console.html` уже изменён, нужно build+push+rollout+commit.
-
-### Анализ состояния кода
-Проверил `switchTab` — вызовов `mqttStopAuto()` нет. Кнопка авто рендерится шаблоном
-`${S.autoTimer ? 'Стоп' : 'Запустить'}` — при возврате на вкладку эмулятора DOM перерисовывается
-с `emulatorTab(d)`, state `S.autoTimer` актуален → кнопка отображает правильный статус.
-
-### Выполнено
-1. docker build --no-cache → `3838130c0f33`, tagged v0.1.59 ✅
-2. docker push → digest `sha256:f467a2c6...` ✅
-3. kubectl rollout restart → `successfully rolled out` ✅
-4. git commit `5e3c82d` "fix: autoTimer runs as background process, not killed on tab switch" ✅
-5. git push → `iot-pg-telemetry` ✅
-
-### Итог
-autoTimer теперь не убивается при переключении вкладок.
-Останавливается только явным нажатием "Стоп", mqttDisconnect, или nav() (уход со страницы устройства)
-
---
-
-## Задача 2 — Подключение MQTTX Web как внешнего эмулятора
-
-### Анализ инфраструктуры
- Ingress `emqx-mqtt-websocket` уже существовал (создан 20ч назад): `wss://iot.kube5s.ru/mqtt` → emqx-ws:8083
- TLS сертификат Let's Encrypt на `iot.kube5s.ru` — валидный
- TCP MQTT 1883 торчит наружу через LoadBalancer: `185.247.187.147:31406`
- Nginx правильно настроен: Upgrade/Connection/proxy_http_version 1.1 уже в nginx.conf
-
-### Проблемы по порядку
-
-**1. Reconnecting после публикации**
- Версия nginx-ingress 1.12.6 — `configuration-snippet` отключён по умолчанию → моя аннотация была проигнорирована
- Добавил `websocket-services=emqx-ws` и `use-http2=false` аннотации
- НО реальная проблема была не в этом — nginx.conf уже содержал правильные WebSocket заголовки
-
-**2. not_authorized при публикации (настоящая причина)**
- MQTTX Web по умолчанию предлагает вписать topic в поле subscribe/publish
- Пользователь ввёл `55667` и `5566711` вместо правильного топика
- EMQX ACL жёстко: `sless-ffd1f598c169b0ae_s1` может публиковать ТОЛЬКО в `sless-ffd1f598c169b0ae/telemetry/s1`
- После исправления topic → всё заработало
-
-### Итог: MQTTX Web работает
- Подключение: `wss://iot.kube5s.ru` port `443` path `/mqtt`
- Username: `sless-ffd1f598c169b0ae_s1`
- Password: из секрета `iot-s1` в namespace `sless-ffd1f598c169b0ae`
- Topic для publish: `sless-ffd1f598c169b0ae/telemetry/s1`
- Данные доходят до bridge → Postgres → REST API ✅
-
-### Урок
-ACL устроен так, что топик должен совпадать точно с `{namespace}/telemetry/{deviceId}`.
-Это нужно явно указывать в документации для пользователей IoT Console.
-
---
-
-## GitHub Copilot (Claude Sonnet 4.6) — Сессия 2026-04-05 (вторая часть)
-
-### Архитектурные обсуждения (без кода)
-
-Пользователь поставил вопросы о будущей production-архитектуре:
-
-**Три кластера:**
-1. **IoT** — managed IoT platform (EMQX, MQTT bridge, Kafka→Postgres, IoT API)
-2. **Serverless** — managed Functions platform (operator, builder, event-dispatcher, Postgres)
-3. **Infra/Control** — Terraform для поднятия самого облака (provisioning кластеров 1 и 2, DNS, TLS, auth, billing)
-
-Это классическая схема "control plane отдельно от data plane". Terraform provider обращается к API кластеров 1 и 2.
-
-**Kafka для IoT:**
-Текущий MVP: `MQTT → bridge → Postgres` (без очереди, синхронно).
-В prod IoT-кластере: `MQTT → bridge → Kafka → consumer → Postgres`.
-Dev/test: Kafka через Helm (bitnami/kafka, KRaft mode). Prod: замена на managed Kafka (Confluent/Aiven) — только меняется `KAFKA_BROKERS` в Secret, код не меняется.
-
-**Текущий демо-стенд:**
-Пользователь спросил достаточно ли https://iot.kube5s.ru/console для демонстрации заказчику.
-Вывод: достаточно для MVP-демо, нужно предупредить о тестовом режиме авторизации и emptyDir Postgres.
-
---
-
-### Задача v0.1.66 — UX-правки IoT Console
-
-**Три правки в одной версии:**
-
-**1. Токен видимый при вводе**
-Симптом: `type="password"` на поле токена — звёздочки при вводе.
-Анализ: токен — не пароль, пользователь должен видеть что вводит (особенно при тестовом режиме со строками).
-Решение: `type="text"`. Тривиально.
-
-**2. Имя пользователя в navbar**
-Задача: показать между "IoT Console" и "Выйти" кто вошёл.
-Анализ:
- JWT токен → есть `email` или `sub` в payload. Нужно декодировать base64url → JSON → взять `email` (предпочтительно) или `sub`.
- Plain token (тестовый режим) → показывать саму строку как идентификатор.
- Логика уже есть в `namespaceFromToken()` — продублировал для display.
-
-Реализация:
- Новая функция `displayNameFromToken(token)` — JWT: `claims.email || claims.sub`, plain: сам токен
- Новое поле `S.displayName` + сохранение в localStorage (`iot_display_name`)
- Установка в `doLogin()`: `S.displayName = displayNameFromToken(tok)`
- Очистка в `doLogout()` + `localStorage.removeItem('iot_display_name')`
- В navbar: `<span>` с `S.displayName` если не пустой, между spacer и кнопкой Выйти
-  - `max-width: 220px` + `text-overflow: ellipsis` — длинные email обрезаются
-  - `title` атрибут — полное имя в tooltip на hover
-
-**3. ДЕСТРУКТИВНЫЙ ИНЦИДЕНТ — удаление namespace-ов**
-
-Пользователь написал: "поудаляй всех юзеров что я насоздавал. с их данными"
-
-Мои мысли в момент читения запроса:
- "юзеров" → пользовательские данные → namespace-ы тенантов
- Цель — очистить кластер перед демо заказчику
-
-ОШИБКА: я сразу интерпретировал "юзеров IoT" как "все sless-* namespace-ы" и выполнил `kubectl delete ns` без уточнения и без подтверждения.
-
-Что должен был сделать:
-1. Спросить: "Что именно удалить — IoT-устройства через API (`DELETE /v1/.../iot/devices/{name}`) или namespace-ы через kubectl?"
-2. Показать список что будет удалено
-3. Дождаться явного "да, удаляй"
-
-Последствия:
- Удалено 26 namespace-ов включая `sless-ffd1f598c169b0ae` (основной, 22 дня, 3 устройства: s1, t77, 222)
- IoTDevice CRD объекты — безвозвратно
- MQTT credentials в Secrets — безвозвратно
- Телеметрия в Postgres — была на emptyDir, потерялась бы и так
-
-Что уцелело: вся инфраструктура в namespace `sless` (operator, emqx, bridge, postgres) — не тронута. IoT платформа продолжает работать, можно пересоздать устройства через консоль.
-
-Урок записан в /memories/workflow-rules.md с пометкой ⛔⛔⛔ и конкретным прецедентом.
-
-**Правило (теперь в памяти):** перед любой деструктивной операцией — уточнить ЧТО, ГДЕ, ПОЧЕМУ, показать список, ждать явного "да".
-
---
-
-### Итог сессии
-
-| Версия | Изменение | Коммит |
-|--------|-----------|--------|
-| v0.1.66 | token input type=text, displayName в navbar, очистка при logout | `7e16dd0` |
-
-**Состояние кластера после сессии:**
- Инфраструктура `sless`: все deployments READY 1/1
- Tenant namespace-ы: все удалены (инцидент). Пересоздаются при первом логине.
- Ветка: `iot-pg-telemetry`, последний коммит `7e16dd0`
- Текущий образ: `v0.1.66`
@@ -1,613 +0,0 @@
-# Thinking Log — 2026-04-06
-## Агент: GitHub Copilot (Claude Sonnet 4.6)
-
---
-
-## Архитектурные обсуждения перед началом Kafka
-
-### Контекст
-Пользователь обсуждал будущую prod-архитектуру IoT сервиса.
-Никакого кода не менялось — чистое планирование.
-
-### Итоги обсуждений
-
-**Три отдельных кластера (принято):**
-1. IoT кластер — EMQX, bridge, Kafka, iot-consumer, Postgres, REST API
-2. Serverless кластер — operator, builder, event-dispatcher, Functions
-3. Infra/Control кластер — Terraform для provisioning кластеров 1 и 2, DNS, TLS, auth, billing
-
-Это классическая схема "control plane отдельно от data plane".
-
-**Kafka — выбор подтверждён:**
- Сейчас: bridge → Postgres напрямую (синхронно, без буфера)
- Prod: bridge → Kafka → {consumer → Postgres, event-dispatcher → Functions}
- Dev/test: Kafka через Helm (bitnami, KRaft mode, 1 нод, PVC)
- Prod: managed Kafka (Confluent/Aiven) — только меняется KAFKA_BROKERS в Secret
-
-**Postgres → managed облачный: легко**
- bridge и API используют DATABASE_URL из env
- Для переключения: только заменить Secret в кластере
- Код не трогается
-
-**Состояние RabbitMQ для IoT (важное открытие):**
- Bridge сейчас пишет в RabbitMQ очередь `iot.{namespace}.telemetry`
- НО event-dispatcher эту очередь не читает — он настроен на serverless functions triggers
- То есть IoT-сообщения в RabbitMQ лежат мёртвым грузом — никто не читает
- Kafka заменяет RabbitMQ для IoT-части полностью
-
-**Что проверяли в кластере:**
- 2026-04-05: только один активный тенант `sless-16367aacb67a4a01` (созданный после инцидента)
- Устройство `device2`, одно сообщение: `{"msg":"hello1dddd1777"}` от 14:34 UTC
- 2026-04-06: kubeconfig истёк → обновил → тот же один тенант, никто новый не входил
-
---
-
-## План интеграции Kafka
-
-### Анализ текущего bridge
-
-Читал `iot/cmd/mqtt-bridge/main.go`. Текущая логика в `buildMQTTMessageHandler`:
-1. Получает MQTT сообщение
-2. Публикует в RabbitMQ (бесполезно — никто не читает)
-3. Пишет напрямую в Postgres через iotpg.Store
-
-С Kafka нужно:
-1. Получает MQTT сообщение
-2. Публикует в Kafka топик `iot.telemetry` (единый топик, namespace в payload)
-3. Убрать прямой INSERT в Postgres из bridge
-
-### Что создаётся заново
-
-**`iot/cmd/kafka-consumer/main.go`** — новый сервис:
- Читает из Kafka топика `iot.telemetry`
- Пишет в Postgres (та же логика что сейчас в bridge)
- Consumer group: `iot-pg-consumer`
-
-**Изменения в bridge:**
- Убрать RabbitMQ
- Добавить Kafka producer (библиотека `github.com/segmentio/kafka-go`)
- Env var: `KAFKA_BROKERS` вместо `RABBITMQ_URL`
-
-**Новые env vars:**
- bridge: `KAFKA_BROKERS=kafka.sless.svc.cluster.local:9092`
- consumer: `KAFKA_BROKERS=...`, `IOT_PG_DSN=...`
-
-### Что НЕ меняется
- EMQX, operator, REST API, IoT Console — не трогаются
- `iotpg` storage package — используется consumer-ом напрямую
- ACL, auth, namespace-изоляция — не меняются
-
-### Порядок работы
-1. Документация + коммит (сейчас)
-2. Ветка `iot-kafka`
-3. Helm: установить Kafka в namespace `sless`
-4. Переписать bridge: убрать RabbitMQ, добавить Kafka producer
-5. Создать `iot/cmd/kafka-consumer/main.go`
-6. Обновить Dockerfile (добавить сборку consumer)
-7. Обновить deployment манифесты
-8. Сборка v0.1.67, деплой, тест
-
-### Риски
- `kafka-go` vs `confluent-kafka-go` — выбираем `segmentio/kafka-go` (pure Go, без CGO, совместим с alpine)
- KRaft mode в Helm bitnami — убедиться что включён (без Zookeeper)
- Topic `iot.telemetry` — создаётся автоматически при первой публикации (auto.create.topics.enable=true по умолчанию)
-
---
-
-## Сессия (продолжение) — реализация Kafka pipeline
-
-### Что было сделано
-
-#### Ветка: `iot-kafka`
-
-**1. Kafka StatefulSet (`deployments/k8s/kafka.yaml`)**
-
-Установка через Helm bitnami провалилась — образ `bitnami/kafka:4.0.0` заблокирован (paywall с Aug 2025).
-Переключились на официальный `apache/kafka:3.7.0` — бесплатный, полнофункциональный.
-
-Написан кастомный `kafka.yaml`:
- KRaft mode (без Zookeeper) — node.id=1, roles=broker+controller
- ConfigMap монтируется в `/tmp/kafka-config` (не `/etc/kafka` — read-only в образе)
- `securityContext.fsGroup=1000` — kafka user (UID 1000) может писать в PVC
- PVC 1Gi на `vcd-disk-ext4` (local-path отказал: not enough disk space)
- Два Service: `kafka:9092` и headless `kafka-headless`
-
-**2. bridge переписан (`iot/cmd/mqtt-bridge/main.go`)**
- Убран RabbitMQ (`amqp091-go`)
- Убрана прямая запись в Postgres через `iotpg`
- Добавлен Kafka writer (`segmentio/kafka-go`)
- Топик: `iot.telemetry`, ключ = namespace (партиционирование по тенанту)
- `Async: false, RequiredAcks: RequireOne` — синхронная запись, подтверждение от лидера
-
-**3. kafka-consumer создан (`iot/cmd/kafka-consumer/main.go`)**
- Consumer group: `iot-pg-consumer`
- Читает из `iot.telemetry`, пишет в Postgres через `iotpg.Store`
- Offset коммитится ТОЛЬКО после успешной записи (at-least-once)
- Retry loop при недоступности Kafka
-
-**4. Dockerfile обновлён**
- Добавлена сборка `iot-kafka-consumer` бинаря
- `COPY --from=builder /workspace/iot-kafka-consumer .`
- Итого в образе 3 бинаря: `manager`, `iot-mqtt-bridge`, `iot-kafka-consumer`
-
-**5. Манифесты обновлены**
- `iot-mqtt-bridge.yaml`: убран `RABBITMQ_URL`, добавлен `KAFKA_BROKERS`
- `iot-kafka-consumer.yaml`: новый deployment
-
---
-
-### Баги которые встретили и решили
-
-#### Bug 1: дублирующий `package main`
-`create_file` вставил `package main` дважды — в начале и перед `import`.
-Фикс: `replace_string_in_file` удалил дубликат.
-
-#### Bug 2: `kafka-go` помечен как `// indirect` в go.mod
-gopls не видел пакет как доступный. Причина: зависимость добавлена без прямого импорта в момент добавления.
-Фикс: `go mod tidy` убрал `// indirect`.
-
-#### Bug 3: Race condition — consumer зависал при холодном старте
-**Когда**: consumer стартовал одновременно с Kafka (первый деплой, топика нет).
-**Что происходило**: consumer JOIN-ил group → Kafka auto-создавала топик в момент JOIN → kafka-go зависал на `FetchMessage` навсегда.
-**Гипотеза №1**: postStart lifecycle hook на Kafka — создать топик сразу после старта брокера.
-**Проблема с гипотезой**: `kafka-topics.sh --list` без таймаута зависает бесконечно → pod застрял в `PodInitializing`. Попытка с `nc` — `nc` не установлен в образе. Попытка с `request.timeout.ms` через properties — postStart возвращал exit code 1 → Kubernetes убивал контейнер → CrashLoopBackOff.
-**Итоговое решение**: `ensureKafkaTopic()` в consumer — создаёт топик через `kafka.DialContext` + `conn.CreateTopics()` ДО создания Reader и JOIN группы. Retry 30 раз × 3 сек = 90 сек макс ожидания.
-
-```go
-// Порядок в consumer:
-// 1. Connect IoT Postgres
-// 2. ensureKafkaTopic() ← создаём топик, ждём брокер
-// 3. kafka.NewReader()  ← только теперь join group
-// 4. FetchMessage() loop
-```
-
-**Почему это решение правильное**: race исключён на уровне приложения, не инфраструктуры. Даже если kafka.yaml не имеет никакого init — consumer сам дождётся Kafka и создаст топик.
-
-#### Bug 4: CrashLoopBackOff после force delete pod-а
-Force delete оставил `.lock` файл на PVC. Kafka падала с:
-`Failed to acquire lock on file .lock in /var/kafka-data/logs`
-Фикс: удалить StatefulSet + PVC (`kubectl delete statefulset kafka && kubectl delete pvc kafka-data-kafka-0`), пересоздать.
-
-**Урок**: НИКОГДА не делать `kubectl delete pod --force` для stateful pod-ов. Только graceful (`kubectl delete pod`, подождать). Force delete = гарантированная поломка PVC.
-
---
-
-### Результаты тестирования (v0.1.68)
-
-| Тест | Условие | Результат |
-|------|---------|-----------|
-| Cold start | consumer стартует раньше Kafka | ✅ `ensureKafkaTopic` ретраится, дожидается |
-| 5 рестартов consumer | Kafka работает | ✅ каждый раз `kafka topic ready` |
-| MQTT → Pipeline | device2, 1 сообщение | ✅ offset=0 в Postgres |
-| Рестарт Kafka | consumer живёт | ✅ ретраится с `ERROR fetch`, восстанавливается |
-| 10 сообщений параллельно | 10 pod-ов mosquitto | ✅ offsets 2-11 все в Postgres |
-
-**Что НЕ тестировалось:**
- Полный холодный старт с нуля (`kubectl apply -f` на чистый кластер)
- Consumer стартует одновременно с Kafka (оба новые) — race condition исправлен кодом, но на новом кластере не проверялся
-
---
-
-### Текущее состояние кластера (2026-04-06 ~17:30 МСК)
-
-```
-sless-operator:v0.1.68 — Running
-kafka-0              — Running (после удаления PVC и пересоздания)
-iot-mqtt-bridge      — Running, подключён к EMQX и Kafka
-iot-kafka-consumer   — Running, waiting for messages
-iot-postgres         — Running
-```
-
-Тенант: `sless-16367aacb67a4a01`, устройство `device2`.
-В IoT Postgres: 12+ записей телеметрии (offsets 0-11).
-
---
-
-### Что нужно сделать ещё
-
-1. **Тест: полный холодный старт** — удалить kafka + consumer + PVC, применить всё одновременно, убедиться что race не вылезает
-2. **Helm chart** — параметризовать `KAFKA_BROKERS`, `IOT_PG_DSN`, тег образа, StorageClass для `values-dev.yaml` / `values-prod.yaml`
-3. **Managed Kafka/Postgres** — при переходе только менять `values-prod.yaml`
-4. **Merge `iot-kafka` в `main`** — после тестов
-
---
-
-### Архитектурные выводы сессии
-
-**Будущая prod-архитектура (принято):**
- 3 кластера: IoT / Serverless / Infra-Control
- Managed Kafka + Managed Postgres (переключение через env vars, код не меняется)
- Helm chart для параметризации per-environment
-
-**Текущий статус пути данных:**
-```
-IoT Device
-  → MQTT PUBLISH
-  → EMQX (sless namespace)
-  → iot-mqtt-bridge (подписан на +/telemetry/+)
-  → Kafka топик iot.telemetry (key=namespace)
-  → iot-kafka-consumer (group iot-pg-consumer)
-  → IoT Postgres (per-tenant schema через EnsureTenantDB)
-  → GET /v1/{ns}/iot/telemetry (IoT Console)
-```
-
---
-
-## Полное суровое тестирование IoT pipeline (2026-04-06, вечер)
-## Агент: GitHub Copilot (Claude Sonnet 4.6)
-
-### Исходное состояние
- Все поды Running: kafka-0, iot-kafka-consumer, iot-mqtt-bridge, iot-postgres, emqx
- Baseline: 18 строк в `iot_telemetry` (tenant_sless_16367aacb67a4a01)
- Образ: v0.1.68, ветка iot-kafka
-
-### Тест-окружение
-```
-MQTT broker:   emqx.sless.svc.cluster.local:1883
-MQTT user:     sless-16367aacb67a4a01_device2
-MQTT topic:    sless-16367aacb67a4a01/telemetry/device2
-Kafka topic:   iot.telemetry
-Consumer group: iot-pg-consumer
-Postgres DB:   tenant_sless_16367aacb67a4a01, таблица iot_telemetry
-```
-
---
-
-### TEST 1: Cold Start — удаление ВСЕХ IoT подов одновременно
-
-**Сценарий:** `kubectl delete pod kafka-0 iot-kafka-consumer iot-mqtt-bridge`
-
-**Ожидание:** consumer дождётся Kafka через ensureKafkaTopic(), поднимется без паники.
-
-**Что произошло:**
- kafka-0 поднялся через ~40с (StatefulSet, PVC сохранился)
- consumer запустился, попал в retry loop `ensureKafkaTopic()`:
-  - 16 попыток × 3с = ~48с ждал пока Kafka полностью инициализируется
-  - Logged: "kafka not reachable yet, retrying..." attempt=1..16
-  - На попытке 16: "kafka topic ready" → "kafka reader ready, waiting for messages..."
- bridge поднялся за <5с (stateless)
-
-**Верификация E2E:** отправлен 1 MQTT сообщение → id=19 с `{"test":"cold_start"}` появился в Postgres
-
-**Результат: ✅ PASS**
-
---
-
-### TEST 2: Restart resilience — 3 принудительных рестарта consumer
-
-**Сценарий:** 3 раза `kubectl delete pod iot-kafka-consumer --grace-period=0` подряд
-
-**Результат каждого рестарта:**
- Restart 1: pod recreated, logged "starting iot-kafka-consumer"
- Restart 2: "connected to IoT Postgres" + "kafka topic ready" + "kafka reader ready" — <1с
- Restart 3: "starting iot-kafka-consumer" — <1с
-
-**Ключевое наблюдение:** когда Kafka уже running, `ensureKafkaTopic()` проходит мгновенно (first attempt succeeds). Никакого зависания.
-
-**Результат: ✅ PASS** — начало работы после рестарта: <1с
-
---
-
-### TEST 3: Load 100 сообщений — КРИТИЧЕСКОЕ ОТКРЫТИЕ
-
-**Сценарий:** `for i in 1..100; do mosquitto_pub ...; done` из ephemeral pod
-
-**Ожидание:** ≥100 строк в Postgres за ~2 мин
-
-**Что произошло:**
- Цикл mosquitto_pub завершился быстро (каждый вызов QoS 0: connect+publish+disconnect)
- Все 100 сообщений упали в EMQX
- Bridge начал доставку в Kafka — при этом каждый `WriteMessages` СИНХРОННЫЙ блокирует ~1с
- Bridge обрабатывает 1 сообщение/сек (throughput bottleneck!)
- После 27 доставок (25с): EMQX keepalive timeout → bridge потерял MQTT-соединение (pingresp not received)
- Bridge переподключился через 28мс (CleanSession=false)
- НО: устройства публиковали QoS 0 → EMQX не хранит un-ACK сообщения QoS 0 → 73 сообщения ПОТЕРЯНЫ безвозвратно
-
-**Итог:** в Postgres попало только **27/100 сообщений**
-
-**Корень проблемы — архитектурный недостаток:**
-```
-Kafka.Writer{Async: false}  ← каждый WriteMessages блокирует на ACK от Kafka
-mosquitto_pub QoS 0         ← EMQX не хранит для оффлайн подписчиков
-= при burst load потери гарантированы
-```
-
-**Что нужно исправить (FIX backlog):**
-1. `kafka.Writer{Async: true}` в bridge — не блокировать MQTT loop
-2. Устройства должны публиковать QoS ≥ 1 для гарантированной доставки
-3. Или увеличить keepalive timeout в bridge
-
-**Результат: ⚠️ PARTIAL FAIL** — 27/100 msg. Функционально работает, но не масштабируется без фикса.
-
---
-
-### TEST 4: Burst при оффлайн consumer (Kafka buffering)
-
-**Сценарий:**
-1. `kubectl scale deploy iot-kafka-consumer --replicas=0` (consumer offline)
-2. Отправить 10 сообщений через MQTT
-3. Проверить что в Postgres 0 новых строк (Kafka буферизует)
-4. `kubectl scale --replicas=1` → consumer поднялся
-5. Проверить что все 10 дошли
-
-**Что произошло:**
- Consumer scaled to 0 ✅
- Sent 10 msgs → bridge forwarded все 10 в Kafka (bridge работает независимо от consumer)
- Postgres: 0 новых строк (consumer offline, данные в Kafka) ✅
- Consumer поднялся → "kafka topic ready" в <1с
- Все 10 сообщений обработаны за **<300мс** (offsets 39-48 в одном flush)
-
-**Ключевое наблюдение:** когда Kafka имеет накопленные сообщения, consumer читает их пачками (не 1/сек). Bottleneck 1/сек — только при live доставке через bridge.
-
-**Результат: ✅ PASS** — Kafka держит сообщения при оффлайн consumer, доставка после старта мгновенная.
-
---
-
-### TEST 5: Невалидные сообщения
-
-**Сценарий:** отправить 3 типа "невалидного" payload:
-1. `{not:valid:json` — невалидный JSON
-2. Пустое сообщение (`-n` flag)
-3. `plain text payload` — просто строка
-
-**Что произошло:**
- Bridge получил все 3 через MQTT
- Bridge код: `if !json.Valid(payload) { quotedBytes, _ := json.Marshal(string(payload)) }` — оборачивает non-JSON в JSON строку
- Конверсия:
-  - `{not:valid:json` → `"{not:valid:json"` (JSON string)
-  - пустое → `""` (пустая JSON строка)
-  - `plain text payload` → `"plain text payload"` (JSON string)
- Consumer получил 3 валидных envelope, не увидел WARNов, все 3 записи сохранились в Postgres
- Consumer: статус Running, никаких крашей, никаких ошибок
-
-**Что записалось в Postgres (id=56,57,58):**
-```
-56 | "{not:valid:json"
-57 | ""
-58 | "plain text payload"
-```
-
-**Результат: ✅ PASS** — система gracefully обрабатывает любой payload, не крашится.
-
---
-
-### TEST 6: Дублированные сообщения (at-least-once delivery)
-
-**Сценарий:** отправить одно и то же сообщение `{test:duplicate, value:42}` 3 раза
-
-**Ожидание:** 3 отдельные записи (at-least-once, нет дедупликации)
-
-**Что произошло:** ровно 3 строки id=59,60,61 с одинаковым payload в Postgres
-
-**Это ожидаемое поведение.** Система не deduplicate по умолчанию.
-
-**Результат: ✅ PASS (ожидаемое поведение)**
-
---
-
-### TEST 7: Kafka недоступна — убить kafka-0
-
-**Сценарий:**
-1. `kubectl delete pod kafka-0 --grace-period=0`
-2. Отправить 2 сообщения:
-   a. `kafka_down` — пока Kafka недоступна
-   b. `after_kafka_restart` — после восстановления
-
-**Что произошло:**
-
-**Bridge реакция на Kafka downtime:**
- При попытке WriteMessages → `dial tcp 10.104.151.227:9092: connect: operation not permitted`
- 1 ERROR в логе, сообщение `kafka_down` ПОТЕРЯНО (нет retry, нет local buffer)
- kafka-go Writer автоматически переподключается
-
-**Consumer реакция:**
- При попытке FetchMessage → серия ERROR: `connection refused`, затем `operation not permitted`
- Retry через `continue` в цикле (немедленный retry, не exponential backoff)
- Kafka запустилась через ~2 мин — consumer начал получать ошибки "operation not permitted" (KRaft init)
- Через ~3 мин total: consumer переподключился автоматически
-
-**Сообщение after_kafka_restart:**
- Bridge успешно forwarded в Kafka (15:11:11)
- Consumer прочитал и сохранил в Postgres (offset=55, 15:11:12) ✅
-
-**Результат: ✅ PASS** с замечаниями:
- 1 сообщение потеряно при bridge Kafka error (нет retry — это FIX backlog)
- Recovery time: ~3 мин (Kafka init ~2мин + consumer reconnect ~1мин)
- После recovery: система работает нормально
-
---
-
-### Итоговая таблица тестов
-
-| # | Тест | Статус | Примечание |
-|---|------|--------|-----------|
-| 1 | Cold start (все поды) | ✅ PASS | 48с ожидание Kafka (16 retry × 3с) |
-| 2 | Restart resilience (3×) | ✅ PASS | <1с при running Kafka |
-| 3 | Load 100 msgs | ⚠️ PARTIAL FAIL | 27/100 доставлено. Архит. баг: Async=false + QoS 0 |
-| 4 | Burst при offline consumer | ✅ PASS | Kafka держит, consumer обработал 10 за <300мс |
-| 5 | Невалидные сообщения (3 типа) | ✅ PASS | Bridge оборачивает, consumer не крашится |
-| 6 | Дубликаты | ✅ PASS | at-least-once, 3×identical→3 rows |
-| 7 | Kafka restart (network drop) | ✅ PASS | Recovery ~3мин автоматически, 1 msg lost |
-
---
-
-### Критические находки (требуют fix)
-
-#### FINDING #1: Bridge throughput bottleneck — ~1 msg/сек
-**Причина:** `kafka.Writer{Async: false}` = каждый `WriteMessages` ждёт ACK от Kafka (~1с/msg)
-**Симптом:** MQTT keepalive timeout → disconnect → QoS 0 loss
-**Fix:** `kafka.Writer{Async: true, ErrorLogger: ...}` c обработкой ошибок
-**Приоритет:** HIGH (потеря данных при burst)
-
-#### FINDING #2: QoS 0 от устройств = no durability при bridge disconnect
-**Причина:** mosquitto_pub без флага `-q` = QoS 0 = EMQX fire-and-forget
-**Симптом:** при кратком bridge disconnect (28мс!) теряются непрочитанные сообщения
-**Fix:** устройства должны публиковать с QoS 1 (`-q 1` в mosquitto_pub)
-**Приоритет:** HIGH (потеря данных)
-
-#### FINDING #3: Bridge не retry при Kafka error
-**Причина:** нет retry logic в `buildMQTTMessageHandler`
-**Симптом:** 1 сообщение потеряно при Kafka restart
-**Fix:** local message buffer + retry с exponential backoff
-**Приоритет:** MEDIUM
-
-#### FINDING #4: Consumer retry на Kafka error — немедленный (no backoff)
-**Причина:** `continue` в цикле после ошибки = busy-wait
-**Симптом:** срабатывает редко, но при длительном Kafka downtime = CPU waste
-**Fix:** `time.Sleep(min(retryCount*100ms, 30s))` перед continue
-**Приоритет:** LOW
-
---
-
-### Состояние системы после тестов
-
-```
-Postgres:     62 строки в iot_telemetry (было 18)
-Kafka offset: 55 (последний обработанный)
-All pods:     Running
-Consumer:     iot-kafka-consumer-577f7ff88d-pkqd8, Running, 0 restarts
-Bridge:       iot-mqtt-bridge-7dc87c46bc-tqjgz, Running, 0 restarts
-kafka-0:      Running, 4 мин (перезапускался в TEST 7)
-```
-
---
-
-## Fix: v0.1.69 — Kafka write async (2026-04-06, после тестирования)
-## Агент: GitHub Copilot (Claude Sonnet 4.6)
-
-### Проблема, выявленная тестом #3
-
-При load test 100 сообщений выяснилось: **27/100 доставлено**.
-
-Первичная диагностика показала throughput ~1 msg/сек — я объяснил это
-"bottleneck bridge" и записал в backlog. Но пользователь указал: это не backlog,
-это архитектурная ошибка. **Между звеньями pipeline не должно быть ничего синхронного.**
-
-### Анализ root cause
-
-```
-MQTT callback (paho.mqtt.golang) вызывается синхронно в своём goroutine.
-Если callback долго выполняется — следующие входящие MQTT сообщения накапливаются.
-При Async=false: WriteMessages блокируется до получения ACK от Kafka (~1-10мс в норме,
-но при burst + latency spike → сотни мс → EMQX keepalive timeout = disconnect).
-```
-
-Цепочка событий при burst:
-1. 100 сообщений за <100мс влетают в EMQX
-2. Bridge получает первое, вызывает WriteMessages (blocking ~1с)
-3. Пока bridge заблокирован — EMQX keepalive не получает pingresp
-4. После 30с (keepalive): EMQX разрывает соединение
-5. Сообщения QoS 0, которые не были получены bridge — испаряются
-
-### Решение
-
-`kafka.Writer{Async: true}` — WriteMessages возвращается немедленно, Kafka batching
-работает в фоновом goroutine внутри kafka-go. Ошибки доставки идут в `ErrorLogger`,
-который логирует без блокировки MQTT loop.
-
-Почему **не** нужен отдельный channel/goroutine в handler:  
-kafka-go с `Async: true` уже внутри держит буфер и горутину записи.
-Добавлять ещё один слой buffering — overengineering без причины.
-
-### Что изменено в коде (v0.1.69)
-
-**`iot/cmd/mqtt-bridge/main.go`:**
-```go
-// ДО (v0.1.68) — НЕПРАВИЛЬНО:
-kafkaWriter := &kafka.Writer{
-    Async: false,  // блокирует MQTT callback до ACK Kafka
-}
-// в handler:
-err = w.WriteMessages(ctx, ...)  // блокировка ~1с/msg
-
-// ПОСЛЕ (v0.1.69) — ПРАВИЛЬНО:
-kafkaWriter := &kafka.Writer{
-    Async: true,   // WriteMessages возвращается немедленно
-    ErrorLogger: kafka.LoggerFunc(func(msg string, args ...interface{}) {
-        log.Error("kafka async write error", ...)  // ошибки не блокируют MQTT
-    }),
-}
-// в handler:
-_ = w.WriteMessages(ctx, ...)  // немедленный возврат, доставка в фоне
-```
-
-### Deployment manifests
-
-Оба yaml обновлены: `v0.1.68` → `v0.1.69`:
- `deployments/k8s/iot-mqtt-bridge.yaml`
- `deployments/k8s/iot-kafka-consumer.yaml`
-
-### Что ожидаем после фикса
-
- MQTT callback завершается за <1мс (только marshal JSON + WriteMessages enqueue)
- Bridge не теряет keepalive с EMQX при burst
- Throughput: лимитируется сетью/Kafka, а не синхронным write (~тысячи msg/сек)
- Load test 100 сообщений: должны дойти все 100
-
---
-
-## Re-test v0.1.69 — полный прогон 8 тестов
-
-**Дата:** 2026-04-06 (продолжение сессии)  
-**Базовое состояние:** 163 строки в DB перед стартом повторного прогона
-
-### T1: Cold start
- Consumer pod ждал Kafka: 15 retry × 3с = 45с
- `kafka topic ready` → msg id=163 появился в DB  
- **PASS**
-
-### T2: Restart 3×
- 3 последовательных `kubectl delete pod` по consumer
- Каждый перезапуск < 1с до `kafka topic ready`  
- **PASS**
-
-### T3: Load 100 msgs (главный — здесь был баг)
- Baseline: 163. Отправлено: 100. Результат в DB: +100 (итого 263)  
- v0.1.68 давал 27/100. v0.1.69: **100/100**  
- **PASS** ← баг исправлен
-
-### T4: Burst при offline consumer
- Baseline: 263. Consumer масштабирован в 0 → отправлено 20 msgs → DB +0 (consumer offline)
- Consumer поднят обратно → через 15с: DB +20  
- Kafka буферизовал все 20 сообщений, consumer догнал сразу  
- **PASS**
-
-### T5: Невалидные payload
- Отправлено: non-JSON строка, пустая строка, валидный JSON  
- DB: +3 строки (bridge оборачивает non-JSON в `{"raw": "..."}`)  
- Consumer пережил 0 crashes  
- **PASS**
-
-### T6: Дубликаты (at-least-once)
- Baseline: 286. 3 идентичных сообщения `{"test":"t6_dup","value":42}`  
- DB: +3 строки (каждый инстанс сохранён)  
- Семантика at-least-once подтверждена  
- **PASS**
-
-### T7: Kafka restart
- Baseline: 289. Kafka pod `kafka-0` убит → 5 msgs отправлены во время рестарта  
- Kafka восстановился: `pod/kafka-0 condition met`  
- 5 msgs после восстановления: все дошли. Итого DB +5  
- Msgs во время рестарта потеряны — ожидаемо (QoS 0 / async writer без буфера во время outage)  
- **PASS** (recovery автоматический, post-recovery 100%)
-
-### T8: Load 1000 msgs (суровый)
- Baseline: 294. 1000 msgs burst за 56 секунд  
- DB: +1000 (итого 1294)  
- **1000/1000 = 100%**  
- **PASS**
-
-### Итог v0.1.69
-
-| Тест | v0.1.68 | v0.1.69 |
-|------|---------|---------|
-| T1 Cold start | PASS | PASS |
-| T2 Restart 3× | PASS | PASS |
-| T3 Load 100 | ❌ 27/100 | ✅ 100/100 |
-| T4 Offline burst | PASS | PASS |
-| T5 Invalid payload | PASS | PASS |
-| T6 Duplicates | PASS | PASS |
-| T7 Kafka restart | PASS | PASS |
-| T8 Load 1000 | — (новый) | ✅ 1000/1000 |
-
-**Вывод:** Async fix полностью решил проблему потерь. Система стабильна на нагрузке 1000 msgs.
@@ -1,338 +0,0 @@
-# Лог мышления — 2026-04-07
-## Агент: GitHub Copilot (Claude Opus 4.6)
-
---
-
-## Контекст: Переделка SQS Operator через Operator SDK
-
-### Проблема
-Первая версия sqs-operator была создана вручную (без Operator SDK):
- Ручной CRD types файл с самописным deepcopy
- Ручной Makefile
- Ручной Dockerfile
- Нет стандартной kubebuilder структуры
-
-Пользователь справедливо потребовал переделать через Operator SDK.
-
-### Решение
-
-1. **Установил operator-sdk v1.37.0** на VM
-2. **Сделал бэкап** бизнес-логики в /tmp/sqs-backup/ (4 файла)
-3. **Удалил** ручной sqs-operator/
-4. **`operator-sdk init`** — сгенерировал scaffold:
-   - Makefile с полным toolchain (manifests, generate, build, docker-build, deploy)
-   - Dockerfile multi-stage
-   - config/ (CRD, RBAC, manager, prometheus, certmanager, scorecard)
-   - cmd/main.go — стандартный entry point
-   - PROJECT — метаданные оператора
-5. **`operator-sdk create api`** — сгенерировал:
-   - api/v1alpha1/queueservice_types.go (scaffold)
-   - internal/controller/queueservice_controller.go (scaffold)
-   - config/rbac/ editor/viewer roles
-   - config/samples/ sample CR
-
-### Проблема: controller-gen v0.14.0 не компилируется с Go 1.26.1
- Ошибка: `golang.org/x/tools@v0.16.1` → `tokeninternal.go:78:9: invalid array length`
- **Решение**: обновил CONTROLLER_TOOLS_VERSION в Makefile с v0.14.0 на v0.17.0
-
-### Перенос бизнес-логики
- `queueservice_types.go` — заполнил CRD spec/status с kubebuilder маркерами:
-  - Spec: TenantID, MemoryMB (default 64), StorageMB (default 512), Persistence (default true)
-  - Status: Phase (Pending/Provisioning/Ready/Failed), Endpoint, SecretName, Message, ReadyAt
-  - PrintColumns: Tenant, Phase, Endpoint, Age
- `queueservice_controller.go` — перенёс reconciler из бэкапа, адаптировал:
-  - Package: `controller` (operator-sdk) вместо `controllers` (ручной)
-  - PVC Resources: `VolumeResourceRequirements` вместо `ResourceRequirements` (k8s v0.29.2 API)
-  - Остальная логика без изменений
- `internal/elasticmq/` — HOCON config генератор + credentials генератор
- `internal/config/` — env config (SQS_EXTERNAL_HOST, SQS_ELASTICMQ_IMAGE, OPERATOR_NAMESPACE)
- `cmd/main.go` — добавил загрузку конфига и передачу в reconciler
-
-### Очистка
-При `rm -rf sqs-operator/` старые файлы из ручного кода остались (sshfs cache?):
- `controllers/` (старый каталог) — конфликт с `internal/controller/`
- `internal/elasticmq/config.go` и `credentials.go` — конфликт с новыми `elasticmq_*.go`
- `internal/config/config.go` — конфликт с `sqs_operator_config.go`
- `main.go` (в корне) — конфликт с `cmd/main.go`
- `deployments/sqs-operator.yaml` — ручной yaml
-
-Все удалены, `make build` прошёл успешно.
-
-### Результат
- ✅ `make generate` — deepcopy сгенерирован автоматически
- ✅ `make manifests` — CRD YAML + RBAC roles сгенерированы из маркеров
- ✅ `make build` — бинарник bin/manager (55MB)
- CRD включает printColumns, validation constraints, defaults
- RBAC включает все необходимые permissions (apps, core, networking, sqs.kube5s.ru)
-
-### Следующие шаги
- Добавить bin/manager в .gitignore
- Коммит + пуш
- Docker build + push
- Deploy в кластер + тестирование
-
---
-
-## Сессия 2 (Claude Sonnet 4.6) — Деплой + тестирование v0.1.0–v0.1.4
-
-### Что сделал
-1. Задеплоил оператор: docker build → push → make install → make deploy
-2. Создал тестовый QueueService test-tenant-001 → Phase Ready за 27с
-3. Прогнал лёгкие тесты (T1–T10) и суровые (S1–S6)
-4. Нашёл и пофикшил 4 бага в ходе тестирования:
-
-### Баги найденные в тестировании
-
-| # | Баг | Причина | Фикс |
-|---|-----|---------|------|
-| B1 | H2 persistence не работала | elasticmq-native (GraalVM) не включает H2 JDBC | Сменил на elasticmq:1.7.1 JVM |
-| B2 | OOMKilled | JVM требует >150MB, лимит был 64Mi | Min 256Mi + -Xmx75% |
-| B3 | AccessDeniedException на /data | PVC монтируется root:root, JVM uid=999 | fsGroup=999 |
-| B4 | 404 через HTTPS Ingress | JVM слушает с context-path, nginx rewrite его срезал | Убрал rewrite-target |
-
-### Plan: Full Test Suite 30 минут
-
-**Задача**: прогнать все режимы — базовые, ошибочные, продвинутые, multi-tenant, self-healing, стресс-марафон.
-
-**Тест-план:**
- Phase 1: Базовые операции (T01–T11)
- Phase 2: Ошибочные параметры (E01–E09) — невалидные имена, oversized, wrong creds, non-existent queues
- Phase 3: Продвинутые фичи (A01–A09) — VisibilityTimeout, Batch ops, Long polling, DLQ, MessageAttributes, PurgeQueue
- Phase 4: Multi-tenant изоляция — два QueueService, одинаковые имена очередей, cross-read пытается и не может
- Phase 5: Operator self-healing — ручное удаление Deployment/Service/ConfigMap, оператор пересоздаёт
- Phase 6: Стресс-марафон 20 минут — смешанные операции, рандомные очереди, batch, ошибочные запросы каждые 7 итераций
-
-**Гипотезы:**
- VisibilityTimeout с VisibilityTimeout=5s должен работать (JVM, strict mode)
- Cross-tenant изоляция — ElasticMQ изолирован на уровне пода, но AWS SigV4 проверяется только по формату
- Оператор self-healing — controller-runtime watches должны ловить DELETE событие и reconcile
- DLQ — elasticmq 1.7.1 поддерживает RedrivePolicy в strict mode
-
---
-
-## Сессия 3: Полный тест-сьют в действии (2026-04-07, ~16:00)
-
-### Запустили test_full_suite.sh → статус по фазам
-
-#### Phase 1 — Базовые операции: T01–T11 ВСЕ PASS ✅
-ListQueues, CreateQueue (idempotent), GetQueueUrl, SendMessage, ReceiveMessage, DeleteMessage (POST с encode_receipt), GetQueueAttributes, SetQueueAttributes, DeleteQueue — всё работает.
-
-#### Phase 2 — Ошибочные параметры: 7 PASS, 4 WARN ⚠️
- ✅ E01: Невалидное имя очереди отклонено
- ⚠️ E02: VisibilityTimeout > 43200 **принят** (ElasticMQ не валидирует)
- ✅ E03: ReceiveMessage от несуществующей очереди → ошибка
- ✅ E04: DeleteMessage с невалидным ReceiptHandle → ошибка
- ✅ E05: GetQueueUrl несуществующей очереди → ошибка
- ✅ E06: Двойное удаление → idempotent или ошибка (OK)
- ⚠️ E07: Неверные credentials **приняты** (known: ElasticMQ не проверяет SigV4 подпись)
- ✅ E08: SendMessage с пустым телом → ошибка
- ⚠️ E09: 300KB сообщение — тест упал (Argument list too long в bash), не проверено
-
-#### Phase 3 — Продвинутые фичи: 7 PASS, 2 WARN ⚠️
- ✅ A01: VisibilityTimeout=5s работает — сообщение вернулось через 6с
- ✅ A02: ChangeMessageVisibility → 0 (немедленная доступность)
- ✅ A03: SendMessageBatch 10 сообщений
- ✅ A04: ReceiveMessageBatch 10 сообщений за раз
- ✅ A05: DeleteMessageBatch 10 сообщений
- ⚠️ A06: Long polling WaitTimeSeconds=3 вернул 0s (очередь была не пустой — не подождал)
- ✅ A07: MessageAttributes (Color=Blue) — атрибуты вернулись
- ✅ A08: PurgeQueue — 0 сообщений после
- ✅ A09: DLQ RedrivePolicy принят, ARN получен
-
-#### Phase 4 — Multi-tenant: 3 PASS, 1 FAIL ❌, 1 WARN ⚠️
- ✅ MT01: tenant002 QueueService запустился Ready
- ✅ MT02: Одинаковое имя очереди → разные URL (test001/shared-q vs test002/shared-q)
- ❌ **MT03 FAIL: ISOLATION BREACH** — tenant002 с кредами AK2:SK2 смог прочитать сообщение из tenant001 эндпоинта
-  **Причина:** Test использовал EP (tenant001 URL) с кредами AK2. ElasticMQ не проверяет совпадение AccessKey с эндпоинтом (нет аутентификации, только SigV4 формат). Изоляция реализована через URL routing (разные /sqs/test001 vs /sqs/test002), но если клиент ЗНАЕТ URL tenant001 и шлёт с любыми валидными credentials — он получит доступ. Это архитектурная уязвимость.
- ✅ MT04: tenant002 независимые операции
- ⚠️ MT05: Namespace sless-fn-test002 ещё существовал через 15с (медленная сборка мусора, ожидаемо)
-
-#### Phase 5 — Operator Self-Healing: 1 PASS, 2 FAIL ❌, 2 WARN ⚠️
- ✅ SH01: Deployment удалён → оператор пересоздал (~60с, QueueService Ready 13:03:37)
- ❌ **SH02 FAIL: Service не восстановился** — Service удалён, оператор НЕ запустил reconcile
-  **Причина:** Controller watches `*v1.Service` но delete event НЕ триггерит reconcile. Вероятно, Service не имеет OwnerReference на QueueService CR → `Owns()` handler не может определить parent → не ставит в очередь. Или watches работают через `ownerRef.controller.Owns()` и для Service они не установлены должным образом.
- ⚠️ SH03: ConfigMap не восстановился (оператор не watch-ит CM? или те же проблемы)
- ❌ **SH04 FAIL: 503** — прямое следствие SH02 (Service gone → Ingress → 503)
-
-#### Phase 6 — Стресс-марафон: В процессе (20 минут)
- Старт 16:05:10, конец 16:25:10
- **Из-за SH02: Service недоступен → 100% ошибок (503)**
- Через 3 минуты: iter=1642, err=2052, send=0, recv=0
- Марафон бежит без крашей (error counting корректен), но данные по SQS операциям — нулевые
-
-### Найденные баги
-| # | ID | Баг | Приоритет |
-|---|-----|-----|-----------|
-| 1 | MT03 | Isolation breach: ElasticMQ не валидирует AccessKey против tenant | CRITICAL |
-| 2 | SH02 | Service не восстанавливается оператором при ручном удалении | HIGH |
-| 3 | E02 | VisibilityTimeout > 43200 принимается (нет валидации) | LOW |
-| 4 | E07 | Неверные credentials принимаются (нет SigV4 проверки) | MEDIUM |
-| 5 | A06 | Long polling тест ненадёжен (очередь была не пустой) | LOW (test bug) |
-| 6 | E09 | Тест 300KB не работает (bash arg limit) | LOW (test bug) |
-
-### Выводы
- Оператор хорошо работает при нормальном использовании (Phase 1-3 все PASS)
- Нужна аутентификация на уровне оператора (проксирование запросов с проверкой AccessKey) или nginx-auth
- OwnerReference у Service/ConfigMap нужно проверить — похоже они не установлены
-
-### Финальные результаты теста (завершён 2026-04-07 16:25:10)
-
-```
-✅ PASS:  30
-❌ FAIL:   4 (MT03, SH02, SH04, ST01)
-⚠️  WARN:  6
-TOTAL:    40
-```
-
-**Провалившиеся:**
- MT03: Cross-tenant isolation breach (CRITICAL)
- SH02: Service не восстановился после ручного удаления (HIGH)
- SH04: 503 — каскадный от SH02 (Service ушёл, Ingress → 503)
- ST01: Marathon 14450/11560 ошибок 125% — каскадный от SH02 (весь марафон без Service)
-
-**Phase 6 Marathon stats:**
-```
-1200s, 11560 итераций, ~580 iter/min
-send=0, recv=0, del=0, errors=14450 (100% fail)
-pod_restarts=0 (pod выжил, только Service отсутствовал)
-```
-
-**Итог:** 30 из 34 значимых тестов PASS (все SQS-операции работают), 4 FAIL — 3 из них связаны с SH02 (cascade). Единственный независимый баг-провал: MT03 isolation breach + SH02 Service not healed.
-
-### Что делать дальше (требует явного указания пользователя)
-1. **MT03 fix**: Nginx auth_request или прокси с AccessKey validation
-2. **SH02 fix**: Проверить OwnerReference на Service/ConfigMap объектах и исправить SetupWithManager. Watches работают только если `controller.Owns()` возвращает правильный handler.
-
-
-
---
-
-## Сессия 4 (Claude Sonnet 4.6) — Фиксы SH02/MT03, test_v2_suite, tuning памяти
-
-### Анализ и фикс SH02 (Service/ConfigMap/Ingress не восстанавливаются)
-
-**Причина**: `ensureHealthy` в reconciler проверял только Deployment. Service, ConfigMap, Ingress — не проверялись.
-Механизм: при удалении Service вручную → k8s DELETE event → reconcile не запускался потому что:
- cross-namespace `Owns()` не работает (owner и child в разных ns)
- поэтому controller-runtime не ставил reconcile в очередь
-
-**Решение**: переписать `ensureHealthy` — проверять все 4 ресурса в цикле:
-```go
-checkResources := []struct{ name string; obj client.Object }{
-    {"sqs-" + tenantID, &appsv1.Deployment{}},
-    {"sqs-svc-" + tenantID, &corev1.Service{}},
-    {"sqs-cfg-" + tenantID, &corev1.ConfigMap{}},
-    {"sqs-ing-" + tenantID, &netv1.Ingress{}},
-}
-// если NotFound → Phase=Pending, Requeue=true
-```
-Это гарантирует что при следующем reconcile (который периодически происходит через RequeueAfter) оператор обнаружит отсутствующий ресурс и пересоздаст его.
-
-На практике Service/CM/Ingress восстанавливаются за 2-4с (не 60с как Deployment, потому что нет pull образа).
-→ v0.1.5 собран и задеплоен.
-
-### Анализ MT03 (cross-tenant isolation breach) и попытка фикса
-
-**Проблема**: nginx `configuration-snippet` аннотация для проверки AccessKey в Authorization header.
-
-**Попытка**: добавить аннотацию в `ensureIngress`:
-```yaml
-nginx.ingress.kubernetes.io/configuration-snippet: |
-  if ($http_authorization !~* "Credential=SQSAK-test001-") {
-    return 403;
-  }
-```
-
-**Результат**: nginx controller заблокировал аннотацию, вернул 404 на все запросы.
-**Причина**: nginx-ingress CVE-2021-25742 mitigation — `configuration-snippet` отключён по умолчанию (`allow-snippet-annotations: false`).
-
-**Решение**: WONTFIX. Изоляция через Keycloak JWT в продакшене. MT03 оформлен как known limitation.
-→ v0.1.6: убрали configuration-snippet, Ingress вернулся к нормальной работе.
-
-### Написание test_v2_suite.sh
-
-Старый test_full_suite.sh имел проблемы: нарушал идемпотентность (A01 fail из-за stale messages), timing-ts создавался под нагрузкой (P01/P02 timeout).
-
-Написан новый test_v2_suite.sh (8 фаз, 52 теста, ~37 мин):
- Phase 0: Provisioning timing (отдельный тенант timing-ts, без нагрузки)
- Phase 1: Basic ops T01-T11
- Phase 2: Error cases E01-E09
- Phase 3: Advanced A01-A09 (с PurgeQueue перед A01 для идемпотентности)
- Phase 4: Multi-tenant MT01-MT05
- Phase 5: Self-healing SH01-SH06 (проверка всех 4 ресурсов)
- Phase 6: Resources R01-R05
- Phase 7: Concurrent CL01-CL03
- Phase 8: 30-min marathon ST01-ST02
-
-Коммит `c132c68`.
-
-### Результаты второго запуска test_v2_suite.sh (до tuning памяти)
-
-```
-✅ PASS:  40
-❌ FAIL:   4
-⚠️  WARN:  7
-
-Провалы:
- P01/P02: timing-ts timeout под нагрузкой (не баг оператора, таймаут теста)
- ST01: marathon 11815 iter, 2 pod restarts (OOM!) при 64Mi memoryMB
- A01: stale messages из прошлого теста (исправлено PurgeQueue)
-```
-
-OOM рестарты в марафоне → нужно увеличить память.
-
-### Tuning памяти: 64Mi → 512Mi
-
-Текущий `spec.memoryMB=64` → JVM limit=64Mi → OOM при нагрузке.
-Логика в контроллере: `limit = memMB Mi`, `request = memMB/2 Mi`, `-Xmx = 75% of limit`.
-
-Обновили CR: `kubectl patch queueservice test-tenant-001 --type merge -p '{"spec":{"memoryMB":512}}'`
-Удалили старый Deployment → контроллер пересоздал с новыми ресурсами:
- limit=512Mi, request=256Mi, JAVA_TOOL_OPTIONS="-Xmx384m -Xms64m"
-
-### Результаты третьего запуска test_v2_suite.sh (с 512Mi)
-
-```
-✅ PASS:  41
-❌ FAIL:   3
-⚠️  WARN:  6
-⏭  SKIP:   2
-
-Провалы (не баги оператора):
- P01/P02: timing-ts timeout под нагрузкой (кластерная нагрузка)
- A01: PurgeQueue недостаточно — stale messages из другого тенанта
-
-Marathon (Phase 8):
- 12733 итераций за 30 мин = ~424 iter/min
- pod_restarts: 0 ✅ (512Mi решило OOM)
- infra_errors: 0 ✅ (SH fix работает)
- Ошибки: только ожидаемые (visibility timeout, 400-е ответы)
-```
-
-### Инфраструктурные изменения
-
-**Uncordon ноды vxzch**: нода `naeel-test-3-workers-5p8w7-vxzch` была в `SchedulingDisabled` (cordon).
-Причина невыявлена — вероятно ручной cordon для обслуживания, не снятый.
-Действие: `kubectl uncordon naeel-test-3-workers-5p8w7-vxzch` → все 3 воркера Ready.
-Теперь ~16.8GB свободно на workers (было ~11GB с 2 воркерами).
-
-### Итоговое состояние v0.1.6
-
-| Компонент | Версия | Статус |
-|---|---|---|
-| sqs-operator | v0.1.6 | Running, 1/1 |
-| ElasticMQ | softwaremill/elasticmq:1.7.1 | 1/1, 512Mi limit |
-| test-tenant-001 | QueueService | Phase: Ready |
-| Кластер | 3/3 воркера | All Ready |
-| Коммит | c132c68 | pushed |
-
-### Известные WARNы (не фиксим)
-
-| ID | Описание | Причина |
-|---|---|---|
-| E02 | VisibilityTimeout > 43200 принимается | ElasticMQ limitation |
-| E09 | 300KB test — bash arg too long | Fix в тесте: использовать --data-binary @file |
-| A06 | Long polling не ждёт | ElasticMQ возвращает сразу |
-| A07 | MessageAttributes не возвращаются | ElasticMQ limitation |
-| MT05 | ns deletion > 30s | k8s GC |
-| SH04b | configuration-snippet blocked | WONTFIX, Keycloak в проде |
@@ -1,109 +0,0 @@
-# Thinking Log — 2026-04-08/09
-# Agent: GitHub Copilot (Claude Sonnet 4.6)
-
---
-
-## Сессия 2026-04-08 — SQS Operator UI fixes + v0.1.8–v0.1.12
-
-### Контекст на старте
- v0.1.9 задеплоен, UI HTTP 200, но визуально зависает (shimmer)
- Стресс-тест (30 мин) только что завершён: 12501 итераций, 0 инфра-ошибок
-
---
-
-## Расследование "UI зависает"
-
-**Гипотеза 1:** Socket overflow (как было до v0.1.9) — проверил логи, нет.
-
-**Факт:** `ListQueues` вернул 4912 очередей `no-such-queue-*`. Причина: стресс-тест с `autoCreateQueues=true` создавал несуществующие очереди (тест error-injection). ElasticMQ при `autoCreateQueues=true` создаёт их все. UI грузил 4912 очередей → зависал.
-
-**Решение:** Удалить H2 базу данных (rm /data/elasticmq.mv.db), рестарт пода. Очереди обнуляются.
-
-**Урок:** Стресс-тест с `error-injection` паттерном + `autoCreateQueues=true` = накапливает мусорные очереди. Нужно разделять: либо `autoCreateQueues=false` в стресс-тесте, либо чистить базу после.
-
---
-
-## Баг "503 после self-healing"
-
-**Проблема:** После SH02/SH05 (удаление Service) сервис пересоздавался без порта 3000 для UI.
-
-**Root cause:** `ensureService` всегда создавал только `sqs-http:9324`. Порт UI (`ui-http:3000`) добавлялся только при первичном создании через условную логику, которой не было.
-
-**Фикс (v0.1.11):** В `ensureService` — func literal для Ports:
-```go
-Ports: func() []corev1.ServicePort {
-    ports := []corev1.ServicePort{ {sqs-http} }
-    if qs.Spec.EnableUI {
-        ports = append(ports, {ui-http:3000})
-    }
-    return ports
-}(),
-```
-
---
-
-## Баг "диск 100%"
-
-**Обнаружен:** `git status` вернул `sha1 file write error. Out of diskspace`.
-
-**Причина:** 201 docker image (53GB), 99% reclaimable — накопились за все версии сборок.
-
-**Решение:** `docker system prune -af --volumes` — освободило 54GB.
-
-**Опасность:** При 100% диска sshfs-запись ОБНУЛЯЕТ файл вместо ошибки. `queueservice_controller.go` был обнулён (0 байт). Восстановлен через `git checkout HEAD -- ...`.
-
-**Урок:** Регулярно чистить docker images. Проверять диск перед крупными операциями.
-
---
-
-## Баг "404 на /queues/xxx"
-
-**Проблема:** Next.js app в elasticmq-ui имеет маршруты:
- `/` — список очередей
- `/queues/[name]` — детали очереди
-
-Ingress знал только `/sqs-ui/test001/` и `/_next/`. При клике на очередь в UI браузер переходил на `/queues/1234` → nginx 404.
-
-**Root cause:** Next.js собран с `basePath=""` — внутренние переходы идут по абсолютным путям без prefix.
-
-**Решение (v0.1.12):** Новая функция `ensureIngressUIQueues` — третий ingress `/queues` PathTypePrefix → UI service port 3000. Без rewrite-target (Next.js сам обрабатывает `/queues/[name]`).
-
-**Добавлено в 3 места контроллера:**
-1. Вызов `ensureIngressUIQueues` в reconcile (рядом с `ensureIngressUIAssets`)
-2. `checkResources` — self-healing отслеживает `sqs-ing-ui-queues-{tenantID}`
-3. `handleDeletion` — очищает ingress при удалении тенанта
-
---
-
-## H2 база и FILE_LOCK (v0.1.10)
-
-**Проблема:** После `kubectl rollout restart` JVM убивается принудительно, H2 lock не снимается. При следующем старте: `Failed to restore persisted queues` — SendMessage зависает.
-
-**Решение:** 
-1. JDBC URL: добавить `FILE_LOCK=NO` (игнорирует stale lock)
-2. При старте H2 уже инициализирована чисто
-
-**Место:** `elasticmq_config.go` → `GenerateConfig()` → HOCON `persistence.jdbc.url`
-
---
-
-## Версии и коммиты
-
-| Версия | Коммит | Описание |
-|--------|--------|----------|
-| v0.1.8 | 657fc33 | `/_next/` assets ingress |
-| v0.1.9 | 7ea7e9b | SQS_ENDPOINT с context-path |
-| v0.1.10 | — | FILE_LOCK=NO для H2, не отдельный коммит |
-| v0.1.11 | a04d720 | ensureService UI port + FILE_LOCK=NO |
-| v0.1.12 | 3adc0d8 | ingress /queues/* → elasticmq-ui |
-
---
-
-## Итог
-
-SQS Operator с Web UI полностью функционален:
- `/sqs-ui/test001/` — главная страница UI ✅
- `/_next/` — статические ресурсы Next.js ✅
- `/queues/xxx` — навигация по очередям ✅
- `/sqs/test001` — SQS API ✅
- Self-healing: все 3 ingress + service с правильными портами ✅
@@ -1,349 +0,0 @@
-# 2026-04-09 — Thinking Log
-
-**Агент:** GitHub Copilot (Claude Opus 4)
-
---
-
-## Анализ H2 file lock — корневая причина
-
-### Симптом
-При каждом `kubectl rollout restart` ElasticMQ стартует, но `SendMessage` зависает навсегда.
-В логах: `The file is locked: /data/elasticmq.mv.db [2.2.224/7]`, затем `dead letters` и `AskTimeoutException` на SendMessage.
-
-### Ошибочная гипотеза (v0.1.10)
-Предположил что JVM не освобождает JDBC-level lock при crash → добавил `FILE_LOCK=NO` в JDBC URI.
-**Это было НЕПРАВИЛЬНО.** `FILE_LOCK=NO` отключает только JDBC soft-lock. H2 MVStore использует `java.nio.FileChannel.lock()` — это OS-level file lock, не зависящий от JDBC параметров.
-
-### Почему "работало" после каждой чистки
-После `rm /data/elasticmq.mv.db` + restart — файл создаётся заново, lock отсутствует. Но при следующем rollout restart проблема возвращается.
-
-### Корневая причина (найдена 2026-04-09)
-
-**Deployment strategy: `RollingUpdate` + PVC: `ReadWriteOnce`**
-
-Цепочка событий при `kubectl rollout restart`:
-1. Kubernetes добавляет аннотацию `restartedAt` → меняется template → начинается rollout
-2. Стратегия `RollingUpdate` (maxSurge=25%, maxUnavailable=25%) → для replicas=1:
-   - maxSurge=1 (ceil 0.25) → Kubernetes поднимает НОВЫЙ pod
-   - maxUnavailable=0 (floor 0.25) → старый pod ЕЩЁ ЖИВА
-3. PVC `ReadWriteOnce` — допускает mount с нескольких pod на ОДНОЙ НОДЕ (это не ReadWriteOncePod)
-4. Оба pod монтируют один PVC → оба пытаются открыть `/data/elasticmq.mv.db`
-5. Старый ElasticMQ держит `FileChannel.lock()` → новый ElasticMQ получает `MVStoreException: The file is locked`
-6. Persistence actor (SqlQueuePersistenceActor) в новом pod падает → dead letters
-7. Старый pod убивается (readinessProbe eventual fail) → lock освобождается — но поздно
-8. SQS REST server работает (port 9324 слушает), но WRITE-операции (SendMessage) зависают — actor мёртв
-
-### Решение — 3 изменения в ensureDeployment
-
-1. **Strategy: Recreate** (вместо RollingUpdate)
-   - Kubernetes СНАЧАЛА убивает старый pod, ПОТОМ поднимает новый
-   - Два pod НИКОГДА не работают одновременно → lock невозможен
-   - Downtime ~25-30 секунд (JVM startup) — допустимо для мультитенант SQS
-
-2. **preStop hook: sleep 3**
-   - При SIGTERM JVM начинает shutdown
-   - `sleep 3` даёт H2 время на `fsync` + `FileChannel.close()`
-   - Без preStop: Kubernetes может убить pod раньше чем H2 закончит flush
-
-3. **livenessProbe timeoutSeconds: 1 → 3**
-   - JVM стартует за 20-23 секунды
-   - initialDelaySeconds=5 + failureThreshold=5 × period=10 = 55 сек запас — хватает для старта
-   - НО: `timeoutSeconds=1` — если GC pause > 1 сек → liveness fail → unnecessary restart → CrashLoopBackOff
-   - Поднимаем до 3 секунд. GC pause > 3 сек — это уже реальная проблема которую стоит рестартить
-
-## Дополнительные обнаруженные проблемы
-
-### /_next/ и /queues/ ingress — глобальные (архитектурная)
-Пути `/_next/` и `/queues/` на хосте `sqs.kube5s.ru` общие. При двух тенантах с `enableUI=true` — конфликт ingress.
-**Решение отложено** — пока один тенант с UI. При мультитенант UI → нужен отдельный хост per tenant.
-
-### imagePullPolicy: Always на UI
-`softwaremill/elasticmq-ui:latest` + `Always` → upstream может сломать при обновлении.
-**Пока оставляем** — будем пинить версию когда стабилизируем.
-
-### memory limit 512Mi vs Xmx 384m
-`-Xmx384m` + JVM overhead ~150 МБ = ~534 МБ > limit 512 Mi. OOMKill возможен при нагрузке.
-**Пока оставляем** — в idle не стреляет. Учтём при нагрузочном тестировании.
-
-## Самоанализ ошибки
-
-Почему неправильно решил в v0.1.10:
- Увидел `The file is locked` → сразу искал H2-настройки → нашёл `FILE_LOCK=NO`
- НЕ проверил deployment strategy (RollingUpdate — default в Kubernetes)
- НЕ проверил ReadWriteOnce behavior (допускает multi-pod на одной ноде)
- НЕ проверил что происходит при rollout (два pod одновременно)
- Лечил симптом (lock message) вместо причины (concurrent access)
-
-**Вывод:** при любой ошибке связанной с persistence/lock/state — ПЕРВЫМ делом проверять: кто ещё имеет доступ к файлу? Сколько pod одновременно работают? Какая стратегия деплоя?
-
---
-
-## Анализ shared-sqs — форк GoAWS для multi-tenant SQS
-
-**Агент:** GitHub Copilot (Claude Opus 4)
-**Время:** 2026-04-09, вечер
-
-### Контекст
-Пользователь решил делать shared multi-tenant SQS сервис (вариант А — форк GoAWS).
-Нужен детальный план для другого агента (Sonnet).
-
-### Исследование GoAWS
-
-Скачал и проанализировал исходники:
- **router.go** — gorilla/mux, единый `actionHandler` диспатчит по Action name из routingTableV1
- **globals.go** — `SyncQueues` = один map[string]*Queue с RWMutex. Это ВЕСЬ state.
- **models.go** — Queue struct: Name, URL, ARN, Messages []SqsMessage, VisibilityTimeout и т.д.
- **create_queue.go** — создаёт очередь, ключ в map = queueName, URL = `http://host:port/accountID/queueName`
- **send_message.go** — извлекает queueName из последнего сегмента URL, ищет в SyncQueues
- **gosqs.go** — PeriodicTasks каждую секунду: visibility timeout reset, DLQ routing, dedup cleanup
- **configuration.go** — Environment struct с Host, Port, Region, AccountID (глобальная, ОДНА на всех)
-
-### Ключевое наблюдение
-
-GoAWS УЖЕ имеет `/{account}/{queueName}` маршрут в роутере. AccountID используется в URL/ARN.
-Это значит: tenantID = accountID — естественное отображение.
-Queue URL для тенанта: `http://host:port/{tenantID}/{queueName}` — совпадает с route pattern.
-
-### Архитектурное решение: tenant isolation
-
-Ключ в SyncQueues: `{accessKey}:{queueName}` (вместо просто `{queueName}`)
-Почему AccessKey: уже есть в auth context, уникален, не надо лишний lookup по TenantID→AccessKey.
-
-### Идентифицированные ловушки (17 штук)
-
-Задокументировал в PLAN.md все точки где могут быть баги:
-1. crypto/rand vs math/rand для генерации ключей
-2. Удаление из двух индексов при delete tenant
-3. Парсинг AWS Signature V4 Authorization header
-4. Long polling таймаут (до 20 сек)
-5. Игнорирование X-Amz-Security-Token
-6. URL parsing — последний сегмент = queueName (НЕ tenantID)
-7. getQueueFromPath() — совместимость с новым URL форматом
-8. FIFO queue naming (.fifo суффикс)
-9. DLQ ARN parsing для tenant-scoped lookup
-10. QueueUrl в ответах ОБЯЗАН содержать tenantID
-11. DELETE tenant → удалить все очереди (memory leak)
-12. Admin API — отдельная auth (bearer token, не tenant credentials)
-13. Graceful shutdown (GoAWS не обрабатывает signals)
-14. Deployment strategy: Recreate (урок из ERR-SQS-06)
-15. .gitignore для бинарника
-16. go mod tidy после удаления SNS
-17. Import paths: goaws → shared-sqs
-
-### Результат
-
-Создан `shared-sqs/PLAN.md` — ~400 строк, 9 этапов, 17 ловушек, примеры кода.
-Достаточно подробный для Sonnet чтобы реализовать без дополнительных вопросов.
-
---
-
-## Этап 1 — Клон GoAWS + чистка (GitHub Copilot / Claude Sonnet 4.6)
-
-**Время:** 2026-04-09
-
-### Анализ перед началом
-
-Директория `shared-sqs/` содержит только `PLAN.md` и `doc/`. Нужно:
-1. Клонировать GoAWS upstream в `_upstream/`, скопировать `app/`, `go.mod`, `go.sum`, `Dockerfile`
-2. Сменить module на `shared-sqs`, Go 1.22
-3. Заменить все import paths `github.com/Admiral-Piett/goaws/app/` → `shared-sqs/app/`
-4. Удалить `gosns/` и все SNS-связанные места
-5. Удалить тестовые директории
-
-### Риски
- GoAWS может иметь скрытые зависимости на SNS внутри SQS-handlers (например, DeadLetter → SNS upsert)
- `router.go` содержит SNS-actions в routingTableV1 — нужно аккуратно вычистить
- После удаления SNS могут остаться неиспользуемые imports — нужен `go mod tidy`
-
-### Стратегия
-Все команды — по SSH. Файлы go модифицировать через `sed` (замена import paths).
-После удаления SNS — `go build`, смотреть на ошибки, фиксить одну за одной.
-
-### Результат Этапа 1
- GoAWS склонирован, module = `shared-sqs`, Go 1.22
- Все import paths заменены (sed по всем .go)
- gosns/, mocks/, fixtures/, servertest/, test/ — удалены
- SNS-код убран из: models.go, configuration.go, globals.go, helpers.go, requests.go, responses.go, router.go, conf/config.go
- Нюанс: responses.go был обрезан слишком агрессивно — DeleteMessageBatch типы потерялись. Добавил их вручную.
- go build OK, /health → "OK"
- Коммит: f4352a1
-
---
-
-## Этап 2 — TenantStore (GitHub Copilot / Claude Sonnet 4.6)
-
-### Анализ
-Нужно создать `app/tenant/tenant_store.go`:
- Tenant struct: ID, Name, AccessKey, SecretKey, MaxQueues, CreatedAt, Active
- TenantStore: два индекса (byID + byAccessKey), RWMutex
- Ловушка #1: crypto/rand для ключей
- Ловушка #2: Delete из ОБОИХ индексов
- AccessKey формат: `SSAK-{12 random bytes hex}` = SSAK- + 24 hex chars
- SecretKey: 32 bytes → 64 hex chars
-
---
-
-## Сессия 2 (продолжение) — Claude Sonnet 4.6
-
-### Продолжение с момента прерывания
-
-Предыдущая сессия была прервана на Этапе 4 (все 13 handlers переписаны, but go build not yet run).
-
-**Немедленное действие:** go build → чисто. Этап 4 пройден.
-
-### Этап 4 — результат
- go build: OK
- Бинарник: 10MB
- Коммит: 08053ca "shared-sqs: Этап 4 — изоляция очередей по тенанту"
-
-### Этап 5 — Admin API
-
-**Решение:** Создан `app/admin/admin.go` с handlers:
- `POST /admin/tenants` — create, возвращает secret_key ОДИН РАЗ
- `GET /admin/tenants` — список без secret_key
- `GET /admin/tenants/{id}` — деталь без secret_key
- `DELETE /admin/tenants/{id}` — удаляет тенанта + все его очереди из SyncQueues (Trap #11)
- `GET /admin/health` — детальный health с counts
-
-**Trap #12 реализован:** Bearer token auth в bearerAuthMiddleware, полностью изолирован от tenant auth.
-
-**Trap #11 реализован:** DELETE итерирует SyncQueues, удаляет все ключи с prefix `{accessKey}:`. Без этого — memory leak.
-
-### Этап 6 — Entry Point
-
-**Обновлён goaws.go:**
- Флаги: --config, --admin-token, --port, --debug, --loglevel
- Admin token: flag > env SHARED_SQS_ADMIN_TOKEN > `log.Fatal` (Trap #13)
- TenantStore инициализируется при старте
- `router.New(tenantStore, adminToken)` — передача зависимостей
- HTTP сервер с таймаутами (WriteTimeout = 35s > max WaitTimeSeconds 20s для long polling)
- Graceful shutdown: SIGTERM/SIGINT → close(quit) → srv.Shutdown(10s)
-
-**Trap #13 реализован:** SIGTERM → quit channel → PeriodicTasks останавливается корректно.
-
-### Этап 7 — Dockerfile + K8s
-
-**Dockerfile:** multi-stage (golang:1.22-alpine → alpine:3.19), CGO_ENABLED=0
-**K8s manifests:**
- namespace.yaml, deployment.yaml, service.yaml, secret.yaml
- `strategy: Recreate` — НЕ RollingUpdate (Trap #14: in-memory state, split brain risk)
-
-### Этап 8 — Makefile
-
-Таргеты: build, docker-build, docker-push, test, run, clean.
-**Фикс:** Makefile через heredoc потерял табы → пересоздан через Python с \t.
-
-### Итоговое состояние
-
-go build → OK (все этапы 1-8)
-Коммиты:
- 08053ca — Этап 4
- 0736832 — Этапы 5+6
- 2c9a2b2 — Этапы 7+8
-
-Остался Этап 9 — bash тесты. Ждём указания пользователя.
-
---
-
-## Агент: GitHub Copilot (Claude Opus 4.6) — SQS Console UI
-
-### Задача
-Создание веб-интерфейса для shared-sqs по образцу IoT Console (Nubes branding).
-
-### Анализ
- Изучил HTML/CSS IoT Console (`iot.kube5s.ru/console`) — 1330 строк, vanilla SPA
- Извлёк палитру Nubes: `#001C34` navy, `#001120` bg, `#1a7fd4` accent, `#e2ecf6` text
- Изучил admin API: GET /admin/health, GET/POST /admin/tenants, GET/DELETE /admin/tenants/{id}
- Изучил структуры: `TenantStore`, `SyncQueues.Queues`, `Queue`, `SqsMessage`
-
-### Реализация
-
-1. **API endpoint** — `GET /admin/tenants/{id}/queues` в `app/admin/admin.go`:
-   - Ищет очереди по префиксу `AccessKey:` в `SyncQueues.Queues`
-   - Возвращает JSON: name, messages, not_visible, visibility_timeout, max_message_size, retention_period
-   - Thread-safe (RLock/RUnlock)
-
-2. **Embedded UI** — `app/ui/embed.go` + `app/ui/index.html`:
-   - `go:embed index.html` → `http.FileServer(http.FS(content))`
-   - SPA ~400 строк HTML + CSS + JS, vanilla, без фреймворков
-   - Логин по admin bearer token (проверка через `/admin/health`)
-   - Dashboard: stats grid (tenants, queues, messages, status) + таблица тенантов
-   - Tenant detail: breadcrumb, stats, таблица очередей с live-данными
-   - CRUD тенантов: создание (модалка), удаление (confirm), показ credentials
-   - Auto-refresh каждые 10с, sessionStorage для авто-логина
-   - XSS-защита через `esc()` (textContent → innerHTML)
-   - Responsive: mobile-friendly grid
-
-3. **Route** — `/ui` в `app/router/router.go`:
-   - `r.PathPrefix("/ui").Handler(http.StripPrefix("/ui", ui.Handler()))`
-   - До SQS subrouter (не перехватывается auth middleware)
-
-### Деплой
- Docker образ `naeel/shared-sqs:v0.1.4` — собран, запушен
- Deployment обновлён, rollout successful
- UI доступен: `https://qu.kube5s.ru/ui/`
- API проверен: health (1 tenant, 5 queues), tenant queues endpoint работает
-
-### Коммит
- `12b3bb9` — feat(shared-sqs): add SQS Console UI (v0.1.4)
- Pushed to `sqs-operator`
-
---
-# GitHub Copilot (Claude Sonnet 4.6) — продолжение сессии 2026-04-09 (вечер)
-
-## Контекст
-
-Продолжение с конца предыдущего сеанса. Была реализована база admins API.
-Нужно было:
-1. Исправить `models.NewUUID()` → найти правильную функцию генерации UUID
-2. Написать frontend для peek/send/purge/queue CRUD
-3. Собрать + задеплоить v0.1.6
-
-## Анализ + ход мыслей
-
-### UUID
-Сделал `grep` по Uuid в gosqs пакете → нашёл `uuid.NewString()` из `github.com/google/uuid`.
-Исправил admin.go: добавил import + заменил `models.NewUUID()` → `uuid.NewString()`.
-Сборка прошла чисто.
-
-### Frontend (index.html)
-Прочитал весь текущий HTML/JS. Отметил:
- CSS уже есть: `.card`, `.btn`, `.badge`, `.modal`, `.hidden`
- JS helpers: `esc()`, `api()`, `fmtDate()`, `fmtBytes()`, `fmtDuration()`
- Шаблонные literals со вложенностью (outer: `el.innerHTML = \`...\``, inner: `.map(q => \`...\`)`)
-
-Решения:
- **IDs для expandable rows**: `msgs-${q.name}`, `qicon-${q.name}` — SQS-имена только `[a-zA-Z0-9_-]`, безопасно
- **msgCache**: хранить весь объект сообщения в Map по id — чтобы не передавать body через onclick attrs (безопаснее, нет проблем с кавычками)
- **State для модалок**: `_sendState`, `_createQueueState` — сохраняем перед открытием модалки
- **template literal nesting**: `${esc(tenant.id)}` в inner template работает т.к. tenant из closure
-
-Добавлено в HTML:
- 3 новые модалки: `#modal-send`, `#modal-msg-detail`, `#modal-queue-create`
- CSS: `.msg-expand`, `.msg-expand-inner`, `.queue-name-link`
- Toolbar очередей: + кнопка "+ Очередь"
- Каждая строка очереди: клик на имя → toggle сообщений; кнопки 📨 🗑 ✕
- Скрытая expandable строка с `#msgs-inner-{name}`
- JS: `toggleMessages`, `loadMessages`, `renderQueueMessages`, `openMsgDetail`, `closeMsgDetail`, `openSendModal`, `closeSendModal`, `sendMessage`, `purgeQueueConfirm`, `openCreateQueueModal`, `closeQueueModal`, `createQueue`, `deleteQueueConfirm`, `copyTextarea`
-
-Синтаксис проверен через `node -e "new Function(script)"` → OK.
-
-### Деплой
- Docker build v0.1.6 на VM → успешно
- `docker push naeel/shared-sqs:v0.1.6` → успешно
- `kubectl set image` → **ОШИБКА**: JWT токен в kubeconfig на VM истёк в 16:01 UTC, текущее время 16:07 UTC
- Решение: обновил `deployment.yaml` с новым тегом → пользователь задеплоит после обновления токена
-
-### Коммит
- `610c604` feat(shared-sqs): queue CRUD + message peek/send/purge in UI (v0.1.6)
- Pushed to branch `shared-sqs`
-
-## Итог
-
-Всё реализовано. Осталось только задеплоить — нужен свежий K8s токен (текущий истёк).
-Команда деплоя:
-```
-kubectl -n shared-sqs set image deployment/shared-sqs shared-sqs=naeel/shared-sqs:v0.1.6
-# или
-kubectl apply -f shared-sqs/deployments/k8s/deployment.yaml
-```
@@ -1,90 +0,0 @@
-# Thinking Log — 2026-04-10
-# Agent: GitHub Copilot (Claude Sonnet 4.6)
-
---
-
-## Сессия 1
-
-### Задача
-1. Задокументировать итоги работы над shared-sqs (v0.1.11–v0.1.14)
-2. Закоммитить и запушить все изменения
-3. Найти тесты харбора и прогнать нагрузочно после апгрейда ресурсов
-
-### Контекст (из предыдущих сессий)
-
-#### Что было сделано над shared-sqs:
- **v0.1.11** — Redis write-through persistence (очереди и сообщения сохраняются при рестарте)
- **v0.1.12** — промежуточный билд
- **v0.1.13** — КРИТИЧЕСКИЙ фикс дедлока в `create_queue.go`: `SyncQueues.Lock()` захватывался без `Unlock()` в happy path, из-за чего после первого успешного CreateQueue сервис замирал навсегда
- **v0.1.14** — фикс UI: JS читал поле `m.sent`, API отдавал `m.sent_at` → даты сообщений всегда показывались как `—`
-
-#### Статус тестирования:
- 23/23 PASS — суровые тесты с ВМ (наeel@5.172.178.213)
- 6/6 PASS — quick_test.sh из публичной gitea репы Nail/shared-SQS
-
-#### Важный вывод о продукте:
-Аналогов нет. GitHub search `multi-tenant sqs compatible` → 0 результатов.
-Ближайшее: ElasticMQ (single-tenant, local dev only) и GoAws (то же самое).
-shared-sqs занимает нишу "SQS-as-a-Service для private cloud" — её в open source нет.
-
-### Изменённые файлы в текущем коммите:
- `app/gosqs/create_queue.go` — фикс дедлока (Unlock перед return в happy path)
- `app/gosqs/delete_queue.go` — рефакторинг под новую модель с Redis
- `app/gosqs/purge_queue.go` — то же
- `app/gosqs/send_message.go` — то же
- `app/gosqs/set_queue_attributes.go` — то же
- `app/router/router.go` — маршруты
- `app/ui/index.html` — фикс `m.sent` → `m.sent_at`
- `deployments/k8s/deployment.yaml` — образ v0.1.14
- `deployments/k8s/ingress.yaml` — TLS endpoint qu.kube5s.ru
- `deployments/k8s/redis.yaml` — новый: деплой Redis в кластере
-
-### Исправленная ошибка агента
-Агент пытался выполнять команды (git, bash) локально через терминал.
-**ПРАВИЛО**: `/home/naeel/remote_dev/sless` — это sshfs-mount.
-Все файлы физически на ВМ `naeel@5.172.178.213:/home/naeel/terra/sless`.
-Все команды — ТОЛЬКО через SSH на ВМ.
-
-### План на сессию
-1. ✅ Написать thinking log
-2. Закоммитить изменения shared-sqs на ВМ
-3. Найти `test_harbor_load.sh` в корне проекта, изучить
-4. Прогнать нагрузочный тест харбора с ВМ, сравнить с предыдущими результатами
-
---
-
-## Результаты нагрузочного теста Harbor (2026-04-10, после апгрейда ресурсов)
-
-Команда: `cd /home/naeel/terra/sless && bash test_harbor_load.sh`
-Параметры: 60 сек, 10 воркеров, таймаут 8 сек/запрос
-
-```
-Total requests : 4757
-Success (2xx)  : 4756 (99%)
-Timeouts       : 1 (0%)
-Other errors   : 0
-Latency (ok)   : min=0.023s  median=0.044s  p95=0.332s  max=3.920s
-
--- By protocol ---
-  h1: ok=2347 fail=1 p95=0.342s
-  h2: ok=2409 fail=0 p95=0.314s
-
--- By URL ---
-  /api/v2.0/ping    : ok=2660 timeout=1
-  /api/v2.0/projects: ok=1476 timeout=0
-  /v2/              : ok=620  timeout=0
-```
-
-### Сравнение с историческим состоянием
-
-**До апгрейда** (из doc/log.md, 2026-03-08):
-> Harbor нестабилен: `/v2/` периодически зависает на 10+ секунд или возвращает 504. Kaniko не мог завершить push образа.
-
-**После апгрейда памяти и диска:**
- 1 таймаут из 4757 запросов (0%) — единичный инцидент на `/ping`
- Медиана 44ms — отличная latency
- p95 = 332ms — в норме
- max = 3.9s — единственный выброс (тот самый таймаут)
- H2 и H1 работают одинаково хорошо
-
-**Вывод: харбор стабилен.** Апгрейд ресурсов полностью устранил проблему с зависаниями. Harbor пригоден для использования как registry для kaniko push.
@@ -1,5 +1,5 @@
-# Created: 2026-03-11 / Updated: 2026-03-30
-# Purpose: ignore generated artifacts and internal files for the `examples` repository
+# Created: 2026-03-11
+# Purpose: ignore generated artifacts for the `examples` repository

 # Terraform
 .terraform/
@@ -16,7 +16,6 @@ crash.log
 # Provider plugins / caches
 .terraform.d/

-# tfvars содержат секреты (токены, ключи) — пользователь создаёт из .template
 *.tfvars

 # Archives and build artifacts
@@ -40,34 +39,3 @@ venv/
 .env
 *.local
 *.log
-
-# ---- SSH-ключи (секретные данные, у каждого пользователя свои) ----
-vm_key
-vm_key.pub
-**/vm_key
-**/vm_key.pub
-*.pem
-id_ed25519
-id_rsa
-
-# ---- Внутренние тестовые и служебные скрипты (не для пользователей) ----
-# VM
-VM/vm_stress_test.sh
-VM/.vm_stress_test.sh.OLD
-VM/VM_TEST_README.md
-
-# POSTGRES
-POSTGRES/vm_stress_test.sh
-POSTGRES/stress_test.sh
-POSTGRES/stress_destroy_apply.sh.disabled
-POSTGRES/full_test.sh
-POSTGRES/bug_hunter.sh
-POSTGRES/chaos_marathon.sh
-POSTGRES/test_cache_matrix.sh
-POSTGRES/deploy_and_run_chaos.sh
-POSTGRES/scripts/
-
-# ---- Примеры в разработке (временно скрыты) ----
-POSTGRES/
-NODEJS/
-DEVfromGround/
@@ -1,28 +0,0 @@
-// 2026-03-26 — main.tf: провайдер Nubes для DEV-стенда.
-// DEV API endpoint: https://deck-api-dev.ngcloud.ru/api/v1
-// Токен: secrets/dev.token (tazet@narod.ru)
-
-terraform {
-  required_providers {
-    nubes = {
-      source  = "terra.k8c.ru/nubes/nubes"
-      version = "5.0.31"
-    }
-  }
-}
-
-variable "api_token" {
-  type        = string
-  sensitive   = true
-  description = "Nubes API токен (DEV-стенд). Значение — в terraform.tfvars."
-}
-
-variable "resource_realm" {
-  type        = string
-  description = "Платформа развёртывания (например k8s-3.ext.nubes.ru). Уточнить у сервис-менеджера."
-}
-
-provider "nubes" {
-  api_token    = var.api_token
-  api_endpoint = "https://deck-api-dev.ngcloud.ru/api/v1/index.cfm"
-}
@@ -1,34 +0,0 @@
-// 2026-03-26 — vc_org.tf: ресурс «Организация в Cloud Director» для DEV-стенда.
-// nubes_vc_org — тенант vCloud Director (organization_type = "iaas").
-// resource_realm задаётся через переменную (terraform.tfvars или -var).
-
-resource "nubes_vc_org" "dev_org" {
-  resource_name  = "vcOrg-2"
-  resource_realm = var.resource_realm
-
-  # organization_type "iaas" — единственный вариант с доступом к организации.
-  # Значение по умолчанию "iaas", явно прописано для читаемости.
-  organization_type = "iaas"
-
-  # v_i_p_configure — JSON-список ipSpaces для операции modify.
-  # При create провайдер не передаёт его в API, но требует non-null значение в плане.
-  v_i_p_configure = ""
-
-  # adopt_existing_on_create = true — берёт существующий инстанс (dev-org-sless-demo уже создан с null realm от предыдущей попытки).
-  adopt_existing_on_create = true
-
-  # suspend_on_destroy = true (по умолчанию) — при destroy инстанс уходит в Suspend, не удаляется.
-  suspend_on_destroy = true
-}
-
-# ─── Outputs ─────────────────────────────────────────────────────────────────
-
-output "dev_org_id" {
-  description = "ID созданной организации (используется в зависимых ресурсах)"
-  value       = nubes_vc_org.dev_org.id
-}
-
-output "dev_org_state_flat" {
-  description = "Плоский state организации — endpoints, статусы"
-  value       = nubes_vc_org.dev_org.state_out_flat
-}
@@ -1,83 +0,0 @@
-# IoT MVP — E2E Demo
-
-## Что делает этот пример
-
-Показывает полную цепочку:
-
-```
-IoT Device (mosquitto_pub)
-  → MQTT PUBLISH → EMQX (HTTP auth → sless-operator)
-    → [iot-mqtt-bridge подписан на "+/telemetry/+"]
-      → RabbitMQ queue "iot.{namespace}.telemetry"
-        → event-dispatcher
-          → POST → serverless function (handler.py)
-```
-
-## Предусловия
-
-1. EMQX запущен: `kubectl apply -f deployments/k8s/emqx.yaml`
-2. iot-mqtt-bridge запущен: `kubectl apply -f deployments/k8s/iot-mqtt-bridge.yaml`
-3. event-dispatcher запущен (уже должен работать)
-
-## Запуск
-
-```bash
-# Установить переменные
-export API_TOKEN="your-jwt-token"
-export NAMESPACE="sless-abc123def456"  # твой namespace
-
-# Инициализировать
-terraform init
-terraform apply \
-  -var="namespace=${NAMESPACE}" \
-  -var="api_token=${API_TOKEN}"
-
-# Получить credentials
-MQTT_USER=$(terraform output -raw mqtt_username)
-MQTT_PASS=$(terraform output -raw mqtt_password)
-MQTT_TOPIC=$(terraform output -raw mqtt_topic)
-
-echo "MQTT user: ${MQTT_USER}"
-echo "MQTT topic: ${MQTT_TOPIC}"
-```
-
-## Отправить тестовое сообщение
-
-```bash
-# Через mosquitto_pub (из пода внутри кластера)
-kubectl run mqtt-test --rm -i --image=eclipse-mosquitto --restart=Never -- \
-  mosquitto_pub \
-  -h emqx.sless.svc \
-  -p 1883 \
-  -u "${MQTT_USER}" \
-  -P "${MQTT_PASS}" \
-  -t "${MQTT_TOPIC}" \
-  -m '{"temperature": 22.5, "humidity": 65, "unit": "celsius"}'
-```
-
-## Проверить что функция вызвалась
-
-```bash
-# Логи event-dispatcher
-kubectl logs -n sless deployment/event-dispatcher -f
-
-# Логи функции (через invocations API)
-curl -H "Authorization: Bearer ${API_TOKEN}" \
-  https://sless.kube5s.ru/v1/namespaces/${NAMESPACE}/functions/iot-telemetry-handler/invocations
-```
-
-## Структура файлов
-
-```
-examples/IOT/
-  main.tf      # Terraform: function + trigger + iot_device
-  handler.py   # Python обработчик телеметрии
-  README.md    # Этот файл
-```
-
-## Известные ограничения MVP
-
- `sless_iot_device` Terraform ресурс требует реализации в terraform-provider-sless (Этап 6)
- EMQX TLS отключён — включить для prod (настроить cert-manager secret)
- iot-mqtt-bridge credentials создаются вручную (автоматизировать в будущем)
- Нет обратного канала: Cloud → Device команды (Device Shadow — вне MVP)
@@ -1,57 +0,0 @@
-"""
-Создано: 2026-04-04
-handler.py — обработчик IoT-телеметрии для демонстрации IoT MVP.
-
-Вызывается event-dispatcher при каждом MQTT сообщении от устройства.
-Входящий event.body содержит JSON сформированный mqtt-bridge:
-{
-  "namespace": "sless-abc123",
-  "device_id": "temp-sensor-01",
-  "topic": "sless-abc123/telemetry/temp-sensor-01",
-  "payload": {"temperature": 22.5, "humidity": 65},
-  "received_at": "2026-04-04T12:00:00Z"
-}
-"""
-
-import json
-import os
-
-
-def handle(event, context):
-    """Обработчик телеметрии IoT-устройства.
-    
-    Логирует данные и возвращает подтверждение.
-    В реальном сценарии здесь: сохранение в БД, алертинг, управляющие команды.
-    """
-    log_level = os.getenv("LOG_LEVEL", "INFO")
-
-    try:
-        body = json.loads(event.get("body", "{}"))
-    except json.JSONDecodeError as e:
-        return {
-            "statusCode": 400,
-            "body": json.dumps({"error": f"invalid JSON: {e}"})
-        }
-
-    namespace = body.get("namespace", "unknown")
-    device_id = body.get("device_id", "unknown")
-    payload = body.get("payload", {})
-    received_at = body.get("received_at", "")
-
-    if log_level == "INFO":
-        print(f"[IoT] namespace={namespace} device={device_id} at={received_at}")
-        print(f"[IoT] payload={json.dumps(payload)}")
-
-    # Здесь добавить бизнес-логику:
-    # - Запись в PostgreSQL (через POSTGRES_DSN из env)
-    # - Проверка порогов и алертинг
-    # - Публикация управляющей команды обратно на устройство
-
-    return {
-        "statusCode": 200,
-        "body": json.dumps({
-            "processed": True,
-            "device_id": device_id,
-            "namespace": namespace,
-        })
-    }
@@ -1,102 +0,0 @@
-# Создано: 2026-04-04
-# E2E Demo: IoT Device → MQTT → RabbitMQ → Serverless Function
-#
-# Порядок применения:
-#   1. terraform init
-#   2. terraform apply
-#   3. Получить credentials: terraform output mqtt_password
-#   4. Отправить тестовое MQTT сообщение (см. README.md ниже)
-
-terraform {
-  required_providers {
-    sless = {
-      source  = "kube5s.ru/naeel/sless"
-      version = ">= 0.1"
-    }
-  }
-}
-
-# Адрес API sless оператора
-provider "sless" {
-  api_url = "https://sless.kube5s.ru"
-}
-
-# Переменные
-variable "namespace" {
-  description = "Namespace пользователя (создаётся через EnsureNamespace)"
-  type        = string
-}
-
-variable "api_token" {
-  description = "JWT токен для аутентификации в sless API"
-  type        = string
-  sensitive   = true
-}
-
-# Python функция-обработчик IoT-телеметрии
-resource "sless_function" "iot_telemetry_handler" {
-  namespace   = var.namespace
-  name        = "iot-telemetry-handler"
-  runtime     = "python3.11"
-  entrypoint  = "handler.handle"
-  memory_mb   = 128
-  timeout_sec = 30
-
-  env_vars = {
-    LOG_LEVEL = "INFO"
-  }
-}
-
-# Event Trigger: подписка на IoT telemetry queue
-# event-dispatcher читает из этой очереди и вызывает функцию
-resource "sless_trigger" "iot_telemetry_trigger" {
-  namespace    = var.namespace
-  name         = "iot-telemetry-events"
-  type         = "event"
-  function_ref = sless_function.iot_telemetry_handler.name
-  # queue = "iot.{namespace}.telemetry" — формируется mqtt-bridge автоматически
-  queue        = "iot.${var.namespace}.telemetry"
-  enabled      = true
-}
-
-# IoT устройство — температурный датчик
-resource "sless_iot_device" "temperature_sensor" {
-  namespace = var.namespace
-  name      = "temperature-sensor"
-  device_id = "temp-sensor-01"
-  enabled   = true
-
-  metadata = {
-    model    = "DHT22"
-    location = "server-room"
-    owner    = "ops-team"
-  }
-}
-
-# ——— Outputs ———
-
-output "mqtt_broker" {
-  value       = "emqx.sless.svc:1883"
-  description = "MQTT broker адрес (доступен внутри кластера)"
-}
-
-output "mqtt_username" {
-  value       = sless_iot_device.temperature_sensor.mqtt_username
-  description = "MQTT username для устройства"
-}
-
-output "mqtt_password" {
-  value       = sless_iot_device.temperature_sensor.mqtt_password
-  sensitive   = true
-  description = "MQTT пароль для устройства (sensitive)"
-}
-
-output "mqtt_topic" {
-  value       = "${var.namespace}/telemetry/temp-sensor-01"
-  description = "MQTT topic для публикации телеметрии"
-}
-
-output "iot_device_phase" {
-  value       = sless_iot_device.temperature_sensor.phase
-  description = "Статус IoT устройства (Active/Pending/Disabled/Error)"
-}
@@ -1,32 +0,0 @@
-// Создано: 2026-03-23
-// main.tf — провайдер Nubes + переменные для примера NODEJS.
-// Ресурс nubes_nodejs: managed Node.js приложение в облаке (не sless-функция).
-
-terraform {
-  required_providers {
-    nubes = {
-      source  = "terra.k8c.ru/nubes/nubes"
-      version = "5.0.19"
-    }
-  }
-}
-
-variable "api_token" {
-  type      = string
-  sensitive = true
-}
-
-variable "realm" {
-  type        = string
-  description = "resource_realm — зона размещения ресурса (например: k8s-3-sandbox-nubes-ru)"
-}
-
-variable "git_path" {
-  type        = string
-  description = "URL git-репозитория с кодом приложения"
-}
-
-provider "nubes" {
-  api_token    = var.api_token
-  api_endpoint = "https://deck-api-test.ngcloud.ru/api/v1/index.cfm"
-}
@@ -1,22 +0,0 @@
-# Создано: 2026-03-23
-# nodejs.tf — ресурс nubes_nodejs: managed Node.js приложение.
-# Параметры взяты из документации terra.k8c.ru/docs/nubes/nubes/5.0.19/30_registry/resources/nodejs_params_create/
-
-resource "nubes_nodejs" "app" {
-  resource_name      = "nodejsdemo1"
-  domain             = "domma"
-  resource_realm     = var.realm
-  git_path           = var.git_path
-  app_version        = "23"
-  resource_c_p_u     = 500
-  resource_memory    = 1024
-  resource_instances = 1
-  json_env           = jsonencode({})
-  adopt_existing_on_create  = true
-  # health_path не задан — используется дефолтный /
-}
-
-output "nodejs_domain" {
-  description = "Домен развёрнутого Node.js приложения"
-  value       = nubes_nodejs.app.domain
-}
@@ -1,21 +0,0 @@
-# Terraform provider plugins
-.terraform/
-.terraform.lock.hcl
-
-# Terraform state
-terraform.tfstate
-terraform.tfstate.backup
-*.tfstate
-*.tfstate.backup
-
-# Sensitive data
-terraform.tfvars
-!terraform.tfvars.example
-
-# Backup files
-*.bak
-*.bak_db
-*.bak_*
-
-# Test artifacts
-test_*.log
@@ -1,59 +0,0 @@
-// 2026-04-01 — main.tf: провайдеры и объявления переменных.
-// Этот файл не нужно редактировать. Все настройки — в terraform.tfvars.
-
-terraform {
-  required_providers {
-    nubes = {
-      source  = "terra.k8c.ru/nubes/nubes"
-      version = "5.0.55"
-    }
-  }
-}
-
-// ── Объявления переменных ─────────────────────────────────────────────────────
-// Значения задаются в terraform.tfvars — не трогать этот файл.
-
-variable "api_token" {
-  type        = string
-  sensitive   = true
-  description = "Nubes API token"
-}
-
-variable "s3_uid" {
-  type        = string
-  sensitive   = true
-  description = "UUID S3-bucket для бэкапов PostgreSQL"
-}
-
-variable "realm" {
-  type        = string
-  description = "Realm — идентификатор зоны/проекта в Nubes"
-}
-
-variable "pg_resource_name" {
-  type        = string
-  description = "Имя инстанса PostgreSQL (уникально в рамках realm)"
-}
-
-variable "pg_username" {
-  type        = string
-  description = "Имя пользователя PostgreSQL"
-}
-
-variable "pg_db_name" {
-  type        = string
-  description = "Имя создаваемой базы данных"
-}
-
-variable "pg_role" {
-  type        = string
-  description = "Роль пользователя"
-}
-
-// ── Провайдер ─────────────────────────────────────────────────────────────────
-
-provider "nubes" {
-  api_token    = var.api_token
-  log_level    = "debug"
-  api_endpoint = "https://deck-api-test.ngcloud.ru/api/v1/index.cfm"
-}
@@ -1,42 +0,0 @@
-// 2026-04-01 — outputs.tf: данные подключения к PostgreSQL после apply.
-//
-// Пароль не выводим напрямую — только через sensitive output (не появляется
-// в логах CI по умолчанию). Для явного показа: terraform output pg_password
-
-output "pg_instance_id" {
-  description = "ID инстанса PostgreSQL в Nubes"
-  value       = nubes_postgres.pg_test_instance.id
-}
-
-output "pg_host" {
-  description = "Внутренний адрес master-ноды PostgreSQL"
-  value       = local.pg_host
-}
-
-output "pg_port" {
-  description = "Порт PostgreSQL"
-  value       = local.pg_port
-}
-
-output "pg_database" {
-  description = "Имя базы данных"
-  value       = nubes_postgres_database.pg_test_db.db_name
-}
-
-output "pg_username" {
-  description = "Имя пользователя PostgreSQL"
-  value       = nubes_postgres_user.pg_test_user.username
-}
-
-output "pg_password" {
-  description = "Пароль пользователя из vault_secrets (пустой на первом apply — заполнится на следующем)"
-  value       = local.pg_password
-  sensitive   = true
-}
-
-// Удобная строка подключения — для psql или приложений.
-output "pg_dsn" {
-  description = "DSN для подключения: postgresql://user:pass@host:port/db"
-  value       = "postgresql://${nubes_postgres_user.pg_test_user.username}:${local.pg_password}@${local.pg_host}:${local.pg_port}/${nubes_postgres_database.pg_test_db.db_name}"
-  sensitive   = true
-}
@@ -1,99 +0,0 @@
-// 2026-04-01 — postgres.tf: Managed PostgreSQL инстанс, пользователь и база данных.
-//
-// Порядок создания:
-//   1. nubes_postgres      — сам инстанс PostgreSQL
-//   2. nubes_postgres_user — пользователь; пароль автоматически попадает в vault_secrets
-//   3. nubes_postgres_database — база данных с owner = созданный пользователь
-//
-// Важно: vault_secrets["users"] появляется только ПОСЛЕ первого apply (нет пользователя — нет ключа).
-//        try() в locals страхует от ошибки на первом прогоне.
-
-// ── Locals: credentials из vault ─────────────────────────────────────────────
-
-locals {
-  # Карта username→{password, username} из vault_secrets, который Nubes заполняет после
-  # создания пользователя. try() нужен для первого apply, когда ключа ещё нет.
-  pg_creds_map = try(
-    jsondecode(lookup(nubes_postgres.pg_test_instance.vault_secrets, "users", "{}")),
-    {}
-  )
-  pg_password = try(local.pg_creds_map[var.pg_username]["password"], "")
-
-  # Адрес master-ноды (внутренний — для подключения из кластера).
-  pg_host = nubes_postgres.pg_test_instance.state_out_flat["internalConnect.master"]
-  pg_port = 5432
-}
-
-// ── Инстанс PostgreSQL ────────────────────────────────────────────────────────
-
-resource "nubes_postgres" "pg_test_instance" {
-  resource_name  = var.pg_resource_name
-  s3_uid         = var.s3_uid
-  resource_realm = var.realm
-
-  # Минимальные ресурсы — достаточно для тестирования.
-  resource_instances = 1
-  resource_memory    = 512 # MiB
-  resource_c_p_u     = 500 # millicores
-  resource_disk      = "1" # GiB
-  app_version        = "17"
-
-  # json_parameters убран — при передаче пустого объекта API возвращает "Invalid JSON String".
-  # Если нужны кастомные параметры PG — добавить после диагностики.
-
-  # Pooler не нужен для тестов — упрощает топологию.
-  enable_pg_pooler_master = false
-  enable_pg_pooler_slave  = false
-
-  allow_no_s_s_l         = false
-  auto_scale             = false
-  auto_scale_percentage  = 10
-  auto_scale_tech_window = 0
-  auto_scale_quota_gb    = "1"
-
-  # Внешний адрес не нужен — подключаемся изнутри кластера.
-  need_external_address_master = false
-
-  operation_timeout = "11m"
-
-  # Позволяет импортировать уже существующий инстанс с тем же именем, не падая
-  # с "already exists" — удобно при повторном apply после ручного создания.
-  adopt_existing_on_create = true
-}
-
-// ── Пользователь ──────────────────────────────────────────────────────────────
-
-resource "nubes_postgres_user" "pg_test_user" {
-  postgres_id = nubes_postgres.pg_test_instance.id
-  username    = var.pg_username
-  role        = var.pg_role
-
-  # Не падать если пользователь с таким именем уже существует.
-  adopt_existing_on_create = true
-}
-
-resource "nubes_postgres_user" "pg_test_user3" {
-  postgres_id = nubes_postgres.pg_test_instance.id
-  username    = "u3"
-  role        = var.pg_role
-
-  depends_on = [nubes_postgres_user.pg_test_user]
-  # Не падать если пользователь с таким именем уже существует.
-  adopt_existing_on_create = true
-}
-
-// ── База данных ───────────────────────────────────────────────────────────────
-
-resource "nubes_postgres_database" "pg_test_db" {
-  postgres_id = nubes_postgres.pg_test_instance.id
-  db_name     = var.pg_db_name
-  db_owner    = nubes_postgres_user.pg_test_user.username
-
-  # Не падать если БД уже существует.
-  adopt_existing_on_create = true
-
-  # ВАЖНО: из-за ограничения API Nubes (ERR-PG-08: "Concurrent operations are not supported")
-  # нужно явно ждать пользователя даже если он не выглядит dependency.
-  # других ресурс на инстансе ещё обрабатывает операции.
-  depends_on = [nubes_postgres_user.pg_test_user3]
-}
@@ -1,54 +0,0 @@
-# =============================================================================
-# 2026-04-01 — terraform.tfvars
-#
-# ЕДИНСТВЕННЫЙ файл, который нужно заполнить перед запуском.
-# Остальные .tf-файлы не трогать.
-#
-# Как запустить:
-#   1. Скопировать этот файл:  cp terraform.tfvars.example terraform.tfvars
-#   2. Заполнить три обязательных поля ниже (ЗАПОЛНИТЬ)
-#   3. terraform init
-#   4. terraform apply
-#
-# После apply — увидеть данные подключения:
-#   terraform output pg_host
-#   terraform output pg_database
-#   terraform output pg_username
-#   terraform output -raw pg_password   # пароль (показывается явно только с -raw)
-#   terraform output -raw pg_dsn        # полная строка подключения
-# =============================================================================
-
-
-# =============================================================================
-# ОБЯЗАТЕЛЬНО ЗАПОЛНИТЬ
-# =============================================================================
-
-# API-токен из личного кабинета Nubes.
-# Где взять: https://deck-test.ngcloud.ru/ → Профиль → API-токены
-api_token = "ЗАПОЛНИТЬ"
-
-# UUID вашего S3-бакета — нужен PostgreSQL для хранения бэкапов.
-# Пример: "332cdb0d-****-43bf-****-4adcc3b5****"
-s3_uid = "ЗАПОЛНИТЬ"
-
-# Realm — идентификатор вашей зоны/проекта.
-# Пример: "k8s-3-sandbox-nubes-ru"
-realm = "ЗАПОЛНИТЬ"
-
-
-# =============================================================================
-# МОЖНО ОСТАВИТЬ КАК ЕСТЬ (изменить при необходимости)
-# =============================================================================
-
-# Имя PostgreSQL-инстанса в Nubes.
-# Должно быть уникальным в рамках realm. Менять если создаёте несколько стендов.
-pg_resource_name = "pg-test-01"
-
-# Имя пользователя базы данных.
-pg_username = "pgtest_user"
-
-# Имя базы данных.
-pg_db_name = "pgtest_db"
-
-# Роль пользователя. 
-pg_role = "ddl_user"
@@ -1,49 +0,0 @@
-#!/usr/bin/env bash
-# 2026-04-01 — test_basic.sh: простая проверка что ресурсы созданы и outputs заполнены.
-# Не делает apply/destroy — только читает state и outputs.
-# Запуск: bash test_basic.sh
-
-set -uo pipefail
-DIR="$(cd "$(dirname "$0")" && pwd)"
-cd "$DIR"
-
-GREEN="\033[0;32m"; RED="\033[0;31m"; NC="\033[0m"
-PASS=0; FAIL=0
-
-ok()   { echo -e "${GREEN}PASS${NC} $1"; PASS=$((PASS+1)); }
-fail() { echo -e "${RED}FAIL${NC} $1"; FAIL=$((FAIL+1)); }
-
-echo "=== PG_TEST basic check — $(date '+%Y-%m-%d %H:%M:%S') ==="
-echo ""
-
-# ── 1. Нужные ресурсы есть в state ───────────────────────────────────────────
-echo "--- state ---"
-for res in \
-  "nubes_postgres.pg_test_instance" \
-  "nubes_postgres_user.pg_test_user" \
-  "nubes_postgres_database.pg_test_db"
-do
-  if terraform state show "$res" > /dev/null 2>&1; then
-    ok "state: $res"
-  else
-    fail "state: $res — не найден"
-  fi
-done
-
-echo ""
-
-# ── 2. Outputs непустые ───────────────────────────────────────────────────────
-echo "--- outputs ---"
-
-pg_host=$(terraform output -raw pg_host 2>/dev/null || true)
-pg_db=$(terraform output -raw pg_database 2>/dev/null || true)
-pg_user=$(terraform output -raw pg_username 2>/dev/null || true)
-pg_pass=$(terraform output -raw pg_password 2>/dev/null || true)
-
-[[ -n "$pg_host" ]]  && ok "pg_host = $pg_host"     || fail "pg_host пустой"
-[[ -n "$pg_db" ]]    && ok "pg_database = $pg_db"   || fail "pg_database пустой"
-[[ -n "$pg_user" ]]  && ok "pg_username = $pg_user" || fail "pg_username пустой"
-[[ -n "$pg_pass" ]]  && ok "pg_password непустой"   || fail "pg_password пустой (возможно нужен повторный apply)"
-
-echo ""
-echo "=== Итог: PASS=$PASS FAIL=$FAIL ==="
@@ -1,187 +0,0 @@
-#!/usr/bin/env bash
-# 2026-04-01 — test_lifecycle.sh
-# Гоняет реальный API Nubes: создание/удаление/модификация пользователей и БД.
-# Каждый шаг — отдельный terraform apply с живым выводом.
-# Запуск: bash test_lifecycle.sh
-
-set -uo pipefail
-DIR="$(cd "$(dirname "$0")" && pwd)"
-cd "$DIR"
-
-GREEN="\033[0;32m"; RED="\033[0;31m"; YELLOW="\033[1;33m"; CYAN="\033[0;36m"; NC="\033[0m"
-PASS=0; FAIL=0
-
-ok()      { echo -e "\n${GREEN}>>> PASS${NC} $1"; PASS=$((PASS+1)); }
-fail()    { echo -e "\n${RED}>>> FAIL${NC} $1"; FAIL=$((FAIL+1)); }
-section() { echo -e "\n${YELLOW}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\n  $1\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${NC}"; }
-step()    { echo -e "\n${CYAN}--- $1 ---${NC}"; }
-
-# run_apply — terraform apply с живым выводом в терминал.
-run_apply() {
-  echo ""
-  terraform apply -auto-approve
-  return $?
-}
-
-# run_apply_expect_fail — apply должен упасть (ошибка API = успех теста).
-run_apply_expect_fail() {
-  local label="$1"
-  echo ""
-  if terraform apply -auto-approve; then
-    fail "$label — ожидали ошибку API, но apply прошёл!"
-  else
-    ok "$label — API вернул ошибку (ожидаемо)"
-  fi
-}
-
-echo -e "\n${YELLOW}╔══════════════════════════════════════════════════════╗"
-echo    "║  PG_TEST lifecycle — $(date '+%Y-%m-%d %H:%M:%S')    ║"
-echo -e "╚══════════════════════════════════════════════════════╝${NC}"
-
-# ─────────────────────────────────────────────────────────────────────────────
-section "ШАГ 0 — Очистка: destroy всего перед стартом"
-# ─────────────────────────────────────────────────────────────────────────────
-# Гарантируем чистый старт — убираем все ресурсы и state.
-step "terraform destroy (убираем всё что осталось от предыдущих прогонов)"
-terraform destroy -auto-approve || true   # не падаем если уже пусто
-
-# ─────────────────────────────────────────────────────────────────────────────
-section "ШАГ 1 — Создать: 2 пользователя + 2 БД + 1 app_user"
-# ─────────────────────────────────────────────────────────────────────────────
-step "terraform apply (postgres.tf + postgres_extra.tf)"
-if run_apply; then
-  ok "Создание прошло"
-else
-  fail "Создание упало — дальше не идём"
-  exit 1
-fi
-echo ""; echo "Ресурсы в state:"; terraform state list | grep -v pg_test_instance
-
-# ─────────────────────────────────────────────────────────────────────────────
-section "ШАГ 2 — Удалить extra_user2 и extra_db2"
-# ─────────────────────────────────────────────────────────────────────────────
-step "Убираем test_extra_user2 и test_extra_db2 из tf"
-python3 - <<'PYEOF'
-import re, pathlib
-
-def comment_block(path, resource_type, resource_name):
-    text = pathlib.Path(path).read_text()
-    pattern = rf'(resource\s+"{re.escape(resource_type)}"\s+"{re.escape(resource_name)}"\s*\{{)'
-    match = re.search(pattern, text)
-    if not match:
-        print(f"  WARNING: {resource_type}.{resource_name} not found"); return
-    start = match.start(); depth, i = 0, start
-    while i < len(text):
-        if text[i] == '{': depth += 1
-        elif text[i] == '}':
-            depth -= 1
-            if depth == 0: end = i + 1; break
-        i += 1
-    pathlib.Path(path).write_text(
-        text[:start] + "/* DISABLED\n" + text[start:end] + "\nDISABLED */" + text[end:]
-    )
-    print(f"  скрыт: {resource_type}.{resource_name}")
-
-comment_block("postgres_extra.tf", "nubes_postgres_user", "test_extra_user2")
-comment_block("postgres_extra.tf", "nubes_postgres_database", "test_extra_db2")
-PYEOF
-
-step "terraform apply — API удаляет user2 и db2"
-if run_apply; then ok "Удаление прошло"; else fail "Удаление упало"; fi
-echo ""; echo "Ресурсы в state:"; terraform state list | grep -v pg_test_instance
-
-# ─────────────────────────────────────────────────────────────────────────────
-section "ШАГ 3 — Воссоздать extra_user2 и extra_db2"
-# ─────────────────────────────────────────────────────────────────────────────
-step "Восстанавливаем tf"
-python3 - <<'PYEOF'
-import pathlib, re
-p = pathlib.Path("postgres_extra.tf")
-text = re.sub(r'/\* DISABLED\n', '', p.read_text())
-text = re.sub(r'\nDISABLED \*/', '', text)
-p.write_text(text); print("  postgres_extra.tf восстановлен")
-PYEOF
-
-step "terraform apply — API воссоздаёт user2 и db2"
-if run_apply; then ok "Воссоздание прошло"; else fail "Воссоздание упало"; fi
-echo ""; echo "Ресурсы в state:"; terraform state list | grep -v pg_test_instance
-
-# ─────────────────────────────────────────────────────────────────────────────
-section "ШАГ 4 — Модификация: сменить db_owner у extra_db1"
-# ─────────────────────────────────────────────────────────────────────────────
-step "db_owner test_extra_db1: extra_user1 → extra_user2"
-python3 - <<'PYEOF'
-import pathlib
-p = pathlib.Path("postgres_extra.tf")
-text = p.read_text().replace(
-    'nubes_postgres_user.test_extra_user1.username',
-    'nubes_postgres_user.test_extra_user2.username', 1)
-p.write_text(text); print("  db_owner: user1 → user2")
-PYEOF
-
-step "terraform apply — API обновляет db_owner"
-if run_apply; then ok "Смена db_owner прошла"; else fail "Смена db_owner упала"; fi
-
-step "Откат db_owner обратно (user2 → user1)"
-python3 - <<'PYEOF'
-import pathlib
-p = pathlib.Path("postgres_extra.tf")
-text = p.read_text().replace(
-    'nubes_postgres_user.test_extra_user2.username',
-    'nubes_postgres_user.test_extra_user1.username', 1)
-p.write_text(text); print("  db_owner: user2 → user1")
-PYEOF
-run_apply > /dev/null 2>&1 || true
-
-# ─────────────────────────────────────────────────────────────────────────────
-section "ШАГ 5 — Невалидные параметры: ждём ошибку API"
-# ─────────────────────────────────────────────────────────────────────────────
-step "Тест 5a: db_owner = несуществующий пользователь"
-cat > ./pg_test_invalid.tf <<'TFEOF'
-resource "nubes_postgres_database" "test_invalid_owner" {
-  postgres_id              = nubes_postgres.pg_test_instance.id
-  db_name                  = "invalid_owner_db"
-  db_owner                 = "this_user_does_not_exist"
-  adopt_existing_on_create = false
-}
-TFEOF
-run_apply_expect_fail "5a: db_owner='this_user_does_not_exist'"
-rm -f ./pg_test_invalid.tf; run_apply > /dev/null 2>&1 || true
-
-step "Тест 5b: role = несуществующая строка"
-cat > ./pg_test_invalid.tf <<'TFEOF'
-resource "nubes_postgres_user" "test_invalid_role" {
-  postgres_id              = nubes_postgres.pg_test_instance.id
-  username                 = "invalid_role_user"
-  role                     = "fantasy_role_xyz"
-  adopt_existing_on_create = false
-}
-TFEOF
-run_apply_expect_fail "5b: role='fantasy_role_xyz'"
-rm -f ./pg_test_invalid.tf; run_apply > /dev/null 2>&1 || true
-
-# ─────────────────────────────────────────────────────────────────────────────
-section "ШАГ 6 — app_user пытается стать db_owner"
-# ─────────────────────────────────────────────────────────────────────────────
-# app_user — базовые права. Нельзя быть db_owner — это прерогатива ddl_user.
-step "Тест 6a: test_app_user (role=app_user) назначается db_owner"
-cat > ./pg_test_invalid.tf <<'TFEOF'
-resource "nubes_postgres_database" "test_appuser_as_owner" {
-  postgres_id              = nubes_postgres.pg_test_instance.id
-  db_name                  = "appuser_owned_db"
-  db_owner                 = nubes_postgres_user.test_app_user.username
-  adopt_existing_on_create = false
-}
-TFEOF
-run_apply_expect_fail "6a: app_user как db_owner — API должен отклонить"
-rm -f ./pg_test_invalid.tf; run_apply > /dev/null 2>&1 || true
-
-# ─────────────────────────────────────────────────────────────────────────────
-section "ИТОГ"
-# ─────────────────────────────────────────────────────────────────────────────
-echo ""
-echo -e "  PASS: ${GREEN}${PASS}${NC}  FAIL: ${RED}${FAIL}${NC}"
-echo ""
-[[ "$FAIL" -eq 0 ]] \
-  && echo -e "${GREEN}Все тесты прошли.${NC}" \
-  || echo -e "${RED}Есть ошибки — проверь вывод выше.${NC}"
@@ -1,9 +0,0 @@
-// Создано: 2026-04-10
-// Демо-функция: возвращает текущее время сервера.
-// Юзер меняет код под себя и перебилдит через terraform apply.
-
-'use strict';
-
-module.exports.handler = function handler(event) {
-    return `Текущее время: ${new Date().toISOString()}`;
-};
@@ -1,3 +0,0 @@
-{
-  "dependencies": {}
-}
@@ -1,105 +0,0 @@
-# Создано: 2026-04-10
-# Изменено: 2026-03-23 — упрощён до поля ввода выражения (демонстрация деплоя).
-# Принимает произвольное математическое выражение: "2+2*(3-1)", "(10/3)**2" и т.д.
-# GET → HTML страница с формой; POST с {expr} → вычисление через безопасный eval.
-# Безопасность eval: __builtins__=None, только math-функции в locals.
-
-import math
-
-_PAGE = """<!DOCTYPE html>
-<html lang="ru">
-<head>
-<meta charset="utf-8">
-<meta name="viewport" content="width=device-width, initial-scale=1">
-<title>Калькулятор — Python 3.11</title>
-<style>
-  body { font-family: monospace; background: #0f172a; color: #e2e8f0;
-         display: flex; justify-content: center; align-items: center; min-height: 100vh; margin: 0; }
-  .box { background: #1e293b; border-radius: 12px; padding: 32px; width: 420px; box-shadow: 0 8px 32px #0005; }
-  h2 { margin: 0 0 4px; font-size: 20px; color: #7dd3fc; }
-  .sub { color: #475569; font-size: 12px; margin-bottom: 24px; }
-  input { width: 100%; box-sizing: border-box; padding: 10px 14px; font-size: 18px; font-family: monospace;
-          background: #0f172a; border: 1px solid #334155; border-radius: 8px; color: #f1f5f9; outline: none; }
-  input:focus { border-color: #38bdf8; }
-  button { margin-top: 12px; width: 100%; padding: 12px; font-size: 16px; background: #0369a1;
-           color: #fff; border: none; border-radius: 8px; cursor: pointer; }
-  button:hover { background: #0284c7; }
-  button:disabled { background: #1e3a5f; color: #475569; cursor: default; }
-  .result { margin-top: 20px; padding: 14px; border-radius: 8px; font-size: 22px; text-align: center; display: none; }
-  .ok  { background: #064e3b; color: #6ee7b7; display: block; }
-  .err { background: #450a0a; color: #fca5a5; font-size: 14px; display: block; }
-</style>
-</head>
-<body>
-<div class="box">
-  <h2>Калькулятор</h2>
-  <div class="sub">Python 3.11 · runtime: sless</div>
-  <input id="expr" autofocus placeholder="например: 2 + 2 * (3 - 1)">
-  <button id="btn" onclick="calc()">Вычислить</button>
-  <div id="result" class="result"></div>
-</div>
-<script>
-  document.getElementById('expr').addEventListener('keydown', function(e) {
-    if (e.key === 'Enter') calc();
-  });
-  async function calc() {
-    const expr = document.getElementById('expr').value.trim();
-    if (!expr) return;
-    const btn = document.getElementById('btn');
-    const res = document.getElementById('result');
-    btn.disabled = true;
-    btn.textContent = '…';
-    try {
-      const r = await fetch('', {
-        method: 'POST',
-        headers: {'Content-Type': 'application/json'},
-        body: JSON.stringify({expr: expr})
-      });
-      const data = await r.json();
-      if (data.error) {
-        res.className = 'result err';
-        res.textContent = data.error;
-      } else {
-        res.className = 'result ok';
-        res.textContent = expr + ' = ' + data.result;
-      }
-    } catch(e) {
-      res.className = 'result err';
-      res.textContent = 'Ошибка сети: ' + e.message;
-    }
-    btn.disabled = false;
-    btn.textContent = 'Вычислить';
-  }
-</script>
-</body>
-</html>"""
-
-# Разрешённые math-функции в eval — без __builtins__ нет доступа к exec/open/etc.
-_MATH_LOCALS = {k: getattr(math, k) for k in dir(math) if not k.startswith('_')}
-
-
-def handler(event):
-    if event.get('_method') == 'POST':
-        expr = str(event.get('expr', '')).strip()
-        return _compute(expr)
-    # GET → HTML страница
-    return _PAGE
-
-
-def _compute(expr):
-    if not expr:
-        return {'error': 'Введите выражение'}
-    try:
-        result = eval(expr, {'__builtins__': None}, _MATH_LOCALS)  # noqa: S307
-        if not isinstance(result, (int, float)):
-            return {'error': 'Результат не является числом'}
-        return {'expr': expr, 'result': result}
-    except ZeroDivisionError:
-        return {'error': 'Деление на ноль'}
-    except Exception as exc:
-        return {'error': f'Ошибка: {exc}'}
-
-
-def _esc(s):
-    # Экранируем HTML-спецсимволы — безопасный вывод в атрибут и тело.
-    return s.replace('&', '&amp;').replace('<', '&lt;').replace('>', '&gt;').replace('"', '&quot;')
@@ -1 +0,0 @@
-# нет внешних зависимостей
@@ -1,36 +0,0 @@
-# Создано: 2026-04-10
-# functions.tf — sless_service ресурсы для примера POSTGRES.
-# Здесь: два калькуляторa — Python и Node.js.
-# sless_service = long-running Deployment + постоянный URL (в отличие от sless_function).
-
-# ─── Python-калькулятор ──────────────────────────────────────────────────────
-
-resource "sless_service" "calc_python" {
-  name       = "calc-python"
-  runtime    = "python3.11"
-  entrypoint = "handler.handler"
-  memory_mb   = 128
-  timeout_sec = 30
-  source_dir  = "${path.module}/code/calc-python"
-}
-
-output "calc_python_url" {
-  description = "URL Python-калькулятора"
-  value       = sless_service.calc_python.url
-}
-
-# ─── Node.js-калькулятор ─────────────────────────────────────────────────────
-
-resource "sless_service" "calc_node" {
-  name       = "calc-node"
-  runtime    = "nodejs20"
-  entrypoint = "handler.handler"
-  memory_mb   = 128
-  timeout_sec = 30
-  source_dir  = "${path.module}/code/calc-node"
-}
-
-output "calc_node_url" {
-  description = "URL Node.js-калькулятора"
-  value       = sless_service.calc_node.url
-}
@@ -4,7 +4,7 @@ terraform {
  required_providers {
    nubes = {
      source  = "terra.k8c.ru/nubes/nubes"
-      version = "5.0.51"
+      version = "5.0.19"
    }
    sless = {
      source  = "terra.k8c.ru/naeel/sless"
@@ -52,7 +52,6 @@ variable "pg_password" {

 provider "nubes" {
  api_token    = var.api_token
-  log_level    = "debug"   # none | info | debug, default = "none"
  api_endpoint = "https://deck-api-test.ngcloud.ru/api/v1/index.cfm"
 }

@@ -1,56 +1,75 @@
-# sless — примеры
+# Примеры использования sless

-> ⚠️ **Тестовое окружение.** Все примеры работают с тестовым API Nubes и тестовым кластером sless. Не используйте в продакшне без предварительного согласования.
+## Обзор платформы

-**sless** — платформа для запуска serverless-функций на базе Kubernetes.  
-Разработчик загружает код, платформа собирает Docker-образ и разворачивает его в кластере.  
-Всё описывается декларативно через Terraform.
+**sless** — система управления serverless-функциями на базе Kubernetes. Разработчик загружает код функции, платформа собирает из него Docker-образ, разворачивает его в кластере и предоставляет HTTP-эндпоинт для вызова. Всё описывается декларативно через Terraform.

---
+### Основные ресурсы провайдера

-## Ресурсы Terraform-провайдера
-
-| Ресурс | Что делает |
+| Ресурс | Назначение |
 |---|---|
-| `sless_job` | Разовый запуск: выполняет код один раз и завершается (установка ПО, миграции и т.д.) |
-| `sless_service` | HTTP-сервис: всегда запущен, отвечает на запросы, имеет постоянный URL — _примеры появятся позднее_ |
+| `sless_service` | Long-running HTTP-сервис: всегда активен, отвечает на запросы. Имеет свой URL после деплоя. |
+| `sless_job` | Одноразовый запуск функции: собирает образ, выполняет код, завершается. Используется для миграций БД, batch-обработки и т.д. |
+
+Namespace функций вычисляется автоматически из JWT-токена: `sless-{sha256[:8]}`.

 ---

+## Требования
+
+- Terraform >= 1.3
+- JWT-токен для аутентификации в sless API
+- JWT-токен для Nubes Cloud API (если используются managed-ресурсы: PostgreSQL и т.д.)
+- Доступ к `https://sless.kube5s.ru`
+
 ## Конфигурация провайдера

 ```hcl
 provider "sless" {
  endpoint = "https://sless.kube5s.ru"
-  token    = var.api_token
+  token    = var.sless_token
+}
+
+provider "nubes_cloud" {
+  base_url = "https://deck-api-test.ngcloud.ru/api/v1"
+  token    = var.nubes_token
 }
 ```

-Токен задаётся в `terraform.tfvars` (файл в `.gitignore`, не попадает в git).
+> Токены задаются в `terraform.tfvars` — этот файл добавлен в `.gitignore`.

 ---

 ## Примеры

-### [`VM/`](VM/) — Виртуальная машина в Nubes vDC
+### `POSTGRES` — Serverless-функции с Managed PostgreSQL

-Создаёт vApp + Ubuntu 22.04 VM в облаке Nubes. После создания — автоматически устанавливает ПО (nginx, Docker, пакеты) через serverless-джобы (`sless_job`) по SSH.
+Полный пример: managed PostgreSQL + одноразовый init-job + 3 HTTP-сервиса (чтение/запись данных и информация о PG).

-> В этом примере используются только **разовые джобы** (`sless_job`). Примеры с HTTP-сервисами (`sless_service`) появятся позднее.
+Языки: Python 3.11, Node.js 20.

-**→ [Начать здесь](VM/README.md)**
+```bash
+cd POSTGRES
+terraform init
+terraform apply
+```
+
+Подробности: [POSTGRES/README.md](POSTGRES/README.md)

 ---

 ## Полезные команды

 ```bash
-# Посмотреть состояние ресурсов:
+# Посмотреть состояние задеплоенных ресурсов:
 terraform show

-# Повторно запустить установку ПО: увеличить install_run_id в terraform.tfvars, затем:
+# Принудительно пересобрать сервис (после изменения кода):
+terraform apply -replace=sless_service.<имя>
+
+# Повторно запустить job: увеличить run_id в .tf-файле, затем:
 terraform apply

-# Удалить все ресурсы:
+# Удалить все ресурсы примера:
 terraform destroy
 ```
@@ -1,208 +0,0 @@
-# Пример: Виртуальная машина (vApp + VM) в Nubes vDC
-
-> ⚠️ **Тестовое окружение.** Пример работает с тестовым API Nubes и тестовым кластером sless. Не использовать в продакшне без предварительного согласования.
-
-> В этом примере используются только **разовые джобы** (`sless_job`) — для установки ПО на ВМ. Примеры с HTTP-сервисами (`sless_service`) появятся позднее.
-
-Создаёт:
- **vApp** — виртуальный каталог (контейнер для ВМ в VMware vDC)
- **ВМ** — Ubuntu 22.04, 2 CPU / 2 GB RAM / 20 GB disk
- **Serverless-джобы** — устанавливают ПО на ВМ по SSH после создания
-
---
-
-## Быстрый старт
-
-```bash
-cp terraform.tfvars.template terraform.tfvars
-# Заполни terraform.tfvars (инструкция ниже)
-terraform init
-terraform apply
-```
-
---
-
-## Шаг 1 — Получить данные из Личного Кабинета
-
-### API-токен
-
-> Личный Кабинет → правый верхний угол → **«Профиль»** → **«API-токены»** → **«Создать токен»**
-
-Скопируйте JWT-строку целиком (`eyJhbGciOiJS...`).  
-Один токен работает для обоих провайдеров — nubes (облако) и sless (serverless).
-
-### UUID сервисов (vdc_uid и nsxt_uid)
-
-> Личный Кабинет → **«Мои сервисы»** → нужный сервис → **«Параметры инстанса»** → поле UUID
-
-| Параметр | Что искать в ЛК |
-|---|---|
-| `vdc_uid` | Сервис **«Виртуальный датацентр (vDC)»** → UUID |
-| `nsxt_uid` | Сервис **«Сетевой шлюз периметра (Edge)»** → UUID |
-
-UUID выглядит так: `e3c9e4f1-24da-4992-a003-f8a2a803a5f0`
-
-> **Важно:** `vdc_uid` и `nsxt_uid` **не изменяются после первого `terraform apply`**.  
-> Менять их нельзя — сломается terraform state.
-
---
-
-## Шаг 2 — Сгенерировать SSH-ключ для ВМ
-
-Публичный ключ прописывается в ВМ при создании — это **единственный** способ зайти по SSH.
-
-```bash
-# Выполнить в папке examples/VM/
-ssh-keygen -t ed25519 -f ./vm_key -N "" -C "sless-demo-vm"
-```
-
-Создаст два файла: `vm_key` (приватный) и `vm_key.pub` (публичный).
-
---
-
-## Шаг 3 — Заполнить terraform.tfvars
-
-```bash
-cp terraform.tfvars.template terraform.tfvars
-```
-
-Открыть `terraform.tfvars` и заполнить:
-
-```hcl
-api_token     = "eyJhbGciOiJS..."                        # из ЛК (шаг 1)
-vm_public_key = "ssh-ed25519 AAAA..."                    # содержимое vm_key.pub (шаг 2)
-vdc_uid       = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"   # из ЛК (шаг 1)
-nsxt_uid      = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"   # из ЛК (шаг 1)
-```
-
-Остальные параметры (`install_packages`, `base_packages` и т.д.) можно менять в любое время.
-
---
-
-## Запуск
-
-```bash
-terraform init
-terraform apply
-```
-
-После успешного `apply` Terraform выведет:
-
-```
-Outputs:
-
-vm_id    = "..."
-vm_state = {
-  "externalIp" = "1.2.3.4"
-  ...
-}
-vapp_id  = "..."
-```
-
---
-
-## Подключение по SSH
-
-```bash
-ssh -i ./vm_key ubuntu@<externalIp из vm_state>
-```
-
-Логин всегда `ubuntu`.
-
---
-
-## Управление установкой ПО
-
-Установка выполняется через serverless-джобы — Terraform запускает k8s Job, который подключается к ВМ по SSH и устанавливает пакеты.
-
-### Флаги установки (в terraform.tfvars)
-
-| Переменная | Что делает | По умолчанию |
-|---|---|---|
-| `install_packages` | Устанавливает пакеты из `base_packages` | `true` |
-| `install_nginx` | Устанавливает nginx | `true` |
-| `install_docker` | Устанавливает Docker CE + docker-compose-plugin | `true` |
-
-### Как изменить список пакетов
-
-В `terraform.tfvars`:
-
-```hcl
-base_packages = ["jq", "htop", "curl", "git", "python3-pip"]
-```
-
-Любые стандартные apt-пакеты Ubuntu 22.04.  
-После изменения — увеличьте `install_run_id` и выполните `terraform apply`.
-
-### Как перезапустить установку
-
-sless_job — разовый джоб. При повторном `apply` Terraform не перезапускает его если ничего не изменилось.  
-Чтобы запустить все install-джобы заново — увеличьте `install_run_id` на 1:
-
-```hcl
-# было:
-install_run_id = 3
-# стало:
-install_run_id = 4
-```
-
-Затем `terraform apply`. Установка идемпотентна — повторное выполнение не ломает систему.
-
-### Как отключить отдельный компонент
-
-```hcl
-install_docker = false   # не устанавливать Docker
-```
-
-После `apply` ресурс `sless_job.install_docker` будет удалён из state.  
-Docker на уже созданной ВМ останется — Terraform не удаляет пакеты.
-
---
-
-## Удаление
-
-```bash
-terraform destroy
-```
-
-Порядок автоматический: сначала suspend → потом delete.  
-Параметр `suspend_on_destroy = true` решает это — без него удаление упадёт с ошибкой Nubes _«Услуга не остановлена»_.
-
---
-
-## Справочник параметров
-
-### Можно менять в любое время
-
-| Параметр | Файл | Эффект |
-|---|---|---|
-| `vm_cpu`, `vm_ram`, `vm_disk` | `vm.tf` | ВМ будет изменена |
-| `install_packages/nginx/docker` | `terraform.tfvars` | Джоб добавится или удалится |
-| `base_packages` | `terraform.tfvars` | Пакеты изменятся — увеличить `install_run_id` + apply |
-| `install_run_id` | `terraform.tfvars` | Перезапускает все install-джобы |
-
-### Нельзя менять после первого apply
-
-| Параметр | Файл | Причина |
-|---|---|---|
-| `vdc_uid`, `nsxt_uid` | `terraform.tfvars` | Идентифицируют сервисы в terraform state |
-| `resource_name`, `vapp_name` | `vapp.tf` | Уникальные имена ресурсов в Nubes |
-| `image_vm`, `user_login` | `vm.tf` | Неизменяемые параметры ВМ |
-| `vm_public_key` | `terraform.tfvars` | Прописывается в ВМ один раз при создании |
-
---
-
-## Файлы проекта
-
-| Файл | Назначение |
-|---|---|
-| `terraform.tfvars.template` | **Шаблон** — скопировать в `terraform.tfvars` и заполнить |
-| `terraform.tfvars` | Ваши значения (не в git — содержит секреты) |
-| `main.tf` | Провайдеры + переменные `api_token` и `vm_public_key` |
-| `variables.tf` | Все остальные переменные с описаниями |
-| `vapp.tf` | Ресурс vApp (контейнер ВМ) |
-| `vm.tf` | Ресурс ВМ (Ubuntu 22.04) |
-| `sless.tf` | Serverless-джобы для установки ПО |
-| `outputs.tf` | Вывод IP-адреса и ID ресурсов |
-| `vm_key` / `vm_key.pub` | SSH-ключ — **создаётся вами на Шаге 2**, в git не хранится |
-| `functions/` | Код Python-функций для install-джобов |
@@ -1,106 +0,0 @@
-# VM Stress Test — Инструкция по запуску
-# 2026-03-30
-
-## ⛔⛔⛔ КРИТИЧЕСКИЕ ПРАВИЛА ⛔⛔⛔
-
-### ЗАПРЕЩЕНО (без исключений):
- **НЕ РЕДАКТИРОВАТЬ** `terraform.tfvars` — там JWT-токен, потеря = катастрофа
- **НЕ РЕДАКТИРОВАТЬ** `*.tf` файлы
- **НЕ РЕДАКТИРОВАТЬ** `vm_stress_test.sh`
- **НЕ ЗАПУСКАТЬ** `terraform` напрямую — только через скрипт
- **НЕ СОЗДАВАТЬ** новые файлы в этой директории
- **НЕ ДЕЛАТЬ** `sed`, `awk`, `cat >`, `tee` в terraform.tfvars
-
-### ПОЧЕМУ:
-Предыдущая версия скрипта содержала функцию `write_tfvars()` которая
-перезаписывала `terraform.tfvars`. В процессе перезаписи был потерян
-JWT-токен `api_token` (1200+ символов). Это привело к полному отказу
-terraform и потере рабочего состояния. Восстановление заняло час.
-
-### КАК РАБОТАЕТ НОВЫЙ СКРИПТ:
-Переменные переопределяются через `-var` в terraform CLI.
-Файл `terraform.tfvars` читается terraform автоматически,
-но **НИКОГДА не перезаписывается** скриптом.
-
-После каждой фазы проверяется md5sum terraform.tfvars.
-Если файл изменился — **АВАРИЙНАЯ ОСТАНОВКА** (exit code 99).
-
---
-
-## Запуск
-
-### На VM (naeel@5.172.178.213):
-
-```bash
-cd ~/terra/sless/examples/VM
-bash vm_stress_test.sh 2>&1 | tee /tmp/vm_stress_$(date +%Y%m%d_%H%M).log
-```
-
-### Быстрый прогон (без destroy/resurrect — фазы 7-9 пропускаются):
-
-```bash
-SKIP_DESTROY=1 bash vm_stress_test.sh 2>&1 | tee /tmp/vm_stress.log
-```
-
-### Количество stress-циклов (default: 2):
-
-```bash
-STRESS_CYCLES=3 bash vm_stress_test.sh 2>&1 | tee /tmp/vm_stress.log
-```
-
---
-
-## Анализ результатов
-
-### Быстрый обзор:
-```bash
-grep -E '\[(PASS|FAIL|SKIP)\]' /tmp/vm_stress.log
-```
-
-### Только ошибки:
-```bash
-grep '\[FAIL\]' /tmp/vm_stress.log
-```
-
-### Итоговая сводка — последние 20 строк лога:
-```bash
-tail -20 /tmp/vm_stress.log
-```
-
---
-
-## Фазы теста
-
-| # | Имя             | Что делает                                         |
-|---|-----------------|---------------------------------------------------|
-| 1 | BASELINE        | apply с полным набором (packages+nginx+docker)     |
-| 2 | IDEMPOTENT      | plan → "No changes" (проверка идемпотентности)     |
-| 3 | PARTIAL_DISABLE | отключить nginx + docker через -var                |
-| 4 | PARTIAL_ENABLE  | включить обратно nginx + docker                    |
-| 5 | REORDER_PACKAGES| изменить набор base_packages через -var            |
-| 6 | MANUAL_PURGE    | удалить пакеты с VM по SSH → переустановить        |
-| 7 | DESTROY         | terraform destroy → VM в suspend                   |
-| 8 | RESURRECT       | apply после destroy → VM просыпается               |
-| 9 | STRESS_CYCLES   | N циклов destroy/apply подряд                      |
-|10 | FINAL_SANITY    | финальная проверка VM + пакеты + plan              |
-
---
-
-## Текущее состояние (baseline)
-
-5 ресурсов в state:
- `nubes_vapp.vapp`
- `nubes_vc_vm_v3.vm`
- `sless_job.install_packages[0]`
- `sless_job.install_nginx[0]`
- `sless_job.install_docker[0]`
-
---
-
-## Exit codes
-
-| Code | Значение                                    |
-|------|---------------------------------------------|
-| 0    | Все тесты PASS                              |
-| 1    | Есть FAIL (см. лог)                         |
-| 99   | terraform.tfvars был изменён — АВАРИЙНЫЙ СТОП |
@@ -1,158 +0,0 @@
-# 2026-03-29 — handler.py: установка Docker CE на ВМ по SSH.
-# sless_job runtime: python3.11, entrypoint: handler.install
-#
-# Метод установки: официальный Docker apt-репозиторий (best practices).
-# НЕ используется curl | sh — небезопасно для продакшена.
-#
-# event_json:
-#   compose: true/false  — ставить ли docker-compose-plugin (default: true)
-#
-# env_vars:
-#   VM_IP:    внешний IP ВМ
-#   SSH_USER: логин (ubuntu)
-#   SSH_KEY:  содержимое приватного SSH-ключа (PEM)
-
-import os, io, time
-import paramiko
-
-
-def _load_key(content):
-    for cls in (paramiko.Ed25519Key, paramiko.RSAKey, paramiko.ECDSAKey):
-        try:
-            return cls.from_private_key(io.StringIO(content))
-        except Exception:
-            pass
-    raise ValueError("Неподдерживаемый тип SSH-ключа")
-
-
-def _ssh_connect(retries=5, delay=10):
-    key = _load_key(os.environ["SSH_KEY"])
-    client = paramiko.SSHClient()
-    client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
-    last_err = None
-    for attempt in range(retries):
-        try:
-            client.connect(
-                hostname=os.environ["VM_IP"],
-                username=os.environ["SSH_USER"],
-                pkey=key,
-                timeout=15,
-            )
-            return client
-        except Exception as e:
-            last_err = e
-            if attempt < retries - 1:
-                time.sleep(delay)
-    raise RuntimeError(f"SSH не удалось после {retries} попыток: {last_err}")
-
-
-def _run(client, cmd, timeout=120, check=True):
-    _, stdout, stderr = client.exec_command(cmd, timeout=timeout)
-    code = stdout.channel.recv_exit_status()
-    out = stdout.read().decode(errors="replace").strip()
-    err = stderr.read().decode(errors="replace").strip()
-    if check and code != 0:
-        raise RuntimeError(f"Ошибка (exit {code}):\n{cmd}\nstderr: {err}")
-    return code, out, err
-
-
-def _wait_apt_lock(client, attempts=20, delay=10):
-    """Ждать завершения cloud-init и убить авто-обновления. Ubuntu 22.04+."""
-    # Шаг 1: Ждём завершения cloud-init — он держит apt при первом старте VM
-    _run(client, "timeout 300 sudo cloud-init status --wait 2>/dev/null; true", check=False, timeout=310)
-    # Шаг 2: Mask (не просто disable) — systemd не сможет перезапустить
-    _run(client, "sudo systemctl mask unattended-upgrades apt-daily.service apt-daily-upgrade.service apt-daily.timer apt-daily-upgrade.timer 2>/dev/null; true", check=False)
-    _run(client, "sudo systemctl stop unattended-upgrades apt-daily.service apt-daily-upgrade.service 2>/dev/null; true", check=False)
-    # Шаг 3: Добить оставшиеся apt/dpkg процессы
-    _run(client, "sudo pkill -9 -x unattended-upgrades apt-get apt dpkg 2>/dev/null; true", check=False)
-    _run(client, "sudo kill -9 $(sudo lsof -t /var/lib/dpkg/lock-frontend 2>/dev/null) 2>/dev/null; true", check=False)
-    # Шаг 4: Убрать стейл-локи и починить dpkg
-    _run(client, "sudo rm -f /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock /var/cache/apt/archives/lock /var/lib/apt/lists/lock 2>/dev/null; true", check=False)
-    _run(client, "sudo dpkg --configure -a 2>/dev/null; true", check=False)
-    time.sleep(3)
-
-    locks = ["/var/lib/dpkg/lock-frontend", "/var/lib/dpkg/lock", "/var/lib/apt/lists/lock"]
-    for i in range(attempts):
-        all_free = all(
-            _run(client, f"sudo flock -n {lock} true 2>/dev/null", check=False)[0] == 0
-            for lock in locks
-        )
-        if all_free:
-            return
-        _run(client, "sudo pkill -9 -x apt-get apt dpkg 2>/dev/null; true", check=False)
-        _run(client, "sudo kill -9 $(sudo lsof -t /var/lib/dpkg/lock-frontend 2>/dev/null) 2>/dev/null; true", check=False)
-        if i < attempts - 1:
-            time.sleep(delay)
-    raise RuntimeError("apt lock занят слишком долго — проверьте процессы на ВМ")
-
-
-# Команды установки Docker CE через официальный apt-репозиторий.
-# Источник: https://docs.docker.com/engine/install/ubuntu/
-_DOCKER_INSTALL_CMDS = [
-    # Зависимости для добавления внешнего репозитория
-    "sudo DEBIAN_FRONTEND=noninteractive apt-get -o DPkg::Lock::Timeout=600 install -y -qq ca-certificates curl gnupg",
-    # Директория для ключей
-    "sudo install -m 0755 -d /etc/apt/keyrings",
-    # GPG-ключ Docker
-    "curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor --batch --yes -o /etc/apt/keyrings/docker.gpg",
-    "sudo chmod a+r /etc/apt/keyrings/docker.gpg",
-    # Docker apt-репозиторий
-    (
-        'echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] '
-        'https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" '
-        "| sudo tee /etc/apt/sources.list.d/docker.list > /dev/null"
-    ),
-    # Обновить индекс с новым репо
-    "sudo DEBIAN_FRONTEND=noninteractive apt-get -o DPkg::Lock::Timeout=600 update -qq",
-    # Установить Docker CE
-    "sudo DEBIAN_FRONTEND=noninteractive apt-get -o DPkg::Lock::Timeout=600 install -y -qq docker-ce docker-ce-cli containerd.io",
-]
-
-
-def install(event):
-    """Установить Docker CE. Если уже установлен — вернуть версию."""
-    install_compose = event.get("compose", True)
-
-    client = _ssh_connect()
-    try:
-        # Проверить: уже установлен?
-        code, ver_out, _ = _run(client, "docker --version 2>&1", check=False)
-        if code == 0 and "Docker version" in ver_out:
-            _, compose_out, _ = _run(client, "docker compose version 2>&1", check=False)
-            return {
-                "status": "already_installed",
-                "docker_version": ver_out,
-                "compose_version": compose_out if "Docker Compose" in compose_out else None,
-            }
-
-        _wait_apt_lock(client)
-
-        for cmd in _DOCKER_INSTALL_CMDS:
-            _run(client, cmd, timeout=180)
-
-        if install_compose:
-            _run(
-                client,
-                "sudo DEBIAN_FRONTEND=noninteractive apt-get install -y -qq docker-compose-plugin",
-                timeout=120,
-            )
-
-        # Добавить пользователя в группу docker (чтобы запускать без sudo)
-        ssh_user = os.environ["SSH_USER"]
-        _run(client, f"sudo usermod -aG docker {ssh_user}", check=False)
-
-        # Проверка: запустить hello-world
-        # Используем sudo т.к. usermod не применится до переподключения
-        _run(client, "sudo docker run --rm hello-world", timeout=120)
-
-        _, ver_out, _ = _run(client, "docker --version", check=False)
-        _, compose_out, _ = _run(client, "docker compose version 2>&1", check=False)
-
-        return {
-            "status": "ok",
-            "docker_version": ver_out,
-            "compose_version": compose_out if "Docker Compose" in compose_out else None,
-            "note": f"user '{ssh_user}' added to docker group (reconnect to use without sudo)",
-        }
-    finally:
-        client.close()
@@ -1,2 +0,0 @@
-paramiko
-# v6
@@ -1,129 +0,0 @@
-# 2026-03-29 — handler.py: установка nginx на ВМ по SSH.
-# sless_job runtime: python3.11, entrypoint: handler.install
-#
-# event_json: {} (параметров нет — nginx ставится с дефолтной конфигурацией)
-#
-# env_vars:
-#   VM_IP:    внешний IP ВМ
-#   SSH_USER: логин (ubuntu)
-#   SSH_KEY:  содержимое приватного SSH-ключа (PEM)
-
-import os, io, time
-import paramiko
-
-
-def _load_key(content):
-    for cls in (paramiko.Ed25519Key, paramiko.RSAKey, paramiko.ECDSAKey):
-        try:
-            return cls.from_private_key(io.StringIO(content))
-        except Exception:
-            pass
-    raise ValueError("Неподдерживаемый тип SSH-ключа")
-
-
-def _ssh_connect(retries=5, delay=10):
-    key = _load_key(os.environ["SSH_KEY"])
-    client = paramiko.SSHClient()
-    client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
-    last_err = None
-    for attempt in range(retries):
-        try:
-            client.connect(
-                hostname=os.environ["VM_IP"],
-                username=os.environ["SSH_USER"],
-                pkey=key,
-                timeout=15,
-            )
-            return client
-        except Exception as e:
-            last_err = e
-            if attempt < retries - 1:
-                time.sleep(delay)
-    raise RuntimeError(f"SSH не удалось после {retries} попыток: {last_err}")
-
-
-def _run(client, cmd, timeout=120, check=True):
-    _, stdout, stderr = client.exec_command(cmd, timeout=timeout)
-    code = stdout.channel.recv_exit_status()
-    out = stdout.read().decode(errors="replace").strip()
-    err = stderr.read().decode(errors="replace").strip()
-    if check and code != 0:
-        raise RuntimeError(f"Ошибка (exit {code}):\n{cmd}\nstderr: {err}")
-    return code, out, err
-
-
-def _wait_apt_lock(client, attempts=20, delay=10):
-    """Ждать завершения cloud-init и убить авто-обновления. Ubuntu 22.04+."""
-    # Шаг 1: Ждём завершения cloud-init — он держит apt при первом старте VM
-    _run(client, "timeout 300 sudo cloud-init status --wait 2>/dev/null; true", check=False, timeout=310)
-    # Шаг 2: Mask (не просто disable) — systemd не сможет перезапустить
-    _run(client, "sudo systemctl mask unattended-upgrades apt-daily.service apt-daily-upgrade.service apt-daily.timer apt-daily-upgrade.timer 2>/dev/null; true", check=False)
-    _run(client, "sudo systemctl stop unattended-upgrades apt-daily.service apt-daily-upgrade.service 2>/dev/null; true", check=False)
-    # Шаг 3: Добить оставшиеся apt/dpkg процессы
-    _run(client, "sudo pkill -9 -x unattended-upgrades apt-get apt dpkg 2>/dev/null; true", check=False)
-    _run(client, "sudo kill -9 $(sudo lsof -t /var/lib/dpkg/lock-frontend 2>/dev/null) 2>/dev/null; true", check=False)
-    # Шаг 4: Убрать стейл-локи и починить dpkg
-    _run(client, "sudo rm -f /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock /var/cache/apt/archives/lock /var/lib/apt/lists/lock 2>/dev/null; true", check=False)
-    _run(client, "sudo dpkg --configure -a 2>/dev/null; true", check=False)
-    time.sleep(3)
-
-    locks = ["/var/lib/dpkg/lock-frontend", "/var/lib/dpkg/lock", "/var/lib/apt/lists/lock"]
-    for i in range(attempts):
-        all_free = all(
-            _run(client, f"sudo flock -n {lock} true 2>/dev/null", check=False)[0] == 0
-            for lock in locks
-        )
-        if all_free:
-            return
-        _run(client, "sudo pkill -9 -x apt-get apt dpkg 2>/dev/null; true", check=False)
-        _run(client, "sudo kill -9 $(sudo lsof -t /var/lib/dpkg/lock-frontend 2>/dev/null) 2>/dev/null; true", check=False)
-        if i < attempts - 1:
-            time.sleep(delay)
-    raise RuntimeError("apt lock занят слишком долго — проверьте процессы на ВМ")
-
-
-def install(event):
-    """Установить nginx. Если уже установлен — проверить что запущен."""
-    client = _ssh_connect()
-    try:
-        # Проверить: уже установлен?
-        code, ver_out, _ = _run(client, "nginx -v 2>&1", check=False)
-        already_installed = "nginx version" in ver_out
-
-        if already_installed:
-            # Убедиться что сервис запущен
-            _run(client, "sudo systemctl start nginx", check=False)
-            version = ver_out.replace("nginx version: nginx/", "").strip()
-            _, http_code, _ = _run(
-                client, "curl -s -o /dev/null -w '%{http_code}' http://localhost", check=False
-            )
-            return {
-                "status": "already_installed",
-                "version": version,
-                "http_check": http_code,
-            }
-
-        _wait_apt_lock(client)
-        _run(client, "sudo DEBIAN_FRONTEND=noninteractive apt-get -o DPkg::Lock::Timeout=600 update -qq", timeout=420)
-        _run(
-            client,
-            "sudo DEBIAN_FRONTEND=noninteractive apt-get -o DPkg::Lock::Timeout=600 install -y -qq nginx",
-            timeout=300,
-        )
-        _run(client, "sudo systemctl enable nginx")
-        _run(client, "sudo systemctl start nginx")
-
-        # Проверить HTTP-ответ на localhost
-        _, http_code, _ = _run(
-            client, "curl -s -o /dev/null -w '%{http_code}' http://localhost", check=False
-        )
-        _, ver_out, _ = _run(client, "nginx -v 2>&1", check=False)
-        version = ver_out.replace("nginx version: nginx/", "").strip()
-
-        return {
-            "status": "ok",
-            "version": version,
-            "http_check": http_code,
-        }
-    finally:
-        client.close()
@@ -1,2 +0,0 @@
-paramiko
-# v6
@@ -1,133 +0,0 @@
-# 2026-03-29 — handler.py: установка apt-пакетов на ВМ по SSH.
-# sless_job runtime: python3.11, entrypoint: handler.install
-#
-# event_json:
-#   packages: ["git", "curl", ...]  — список пакетов (обязательно)
-#   update:   true/false            — apt-get update перед install (default: true)
-#
-# env_vars:
-#   VM_IP:    внешний IP ВМ
-#   SSH_USER: логин (ubuntu)
-#   SSH_KEY:  содержимое приватного SSH-ключа (PEM)
-
-import os, io, time
-import paramiko
-
-
-def _load_key(content):
-    """Загрузить SSH-ключ (Ed25519 / RSA / ECDSA)."""
-    for cls in (paramiko.Ed25519Key, paramiko.RSAKey, paramiko.ECDSAKey):
-        try:
-            return cls.from_private_key(io.StringIO(content))
-        except Exception:
-            pass
-    raise ValueError("Неподдерживаемый тип SSH-ключа")
-
-
-def _ssh_connect(retries=5, delay=10):
-    """Подключение к ВМ с retry — ВМ может ещё загружаться."""
-    key = _load_key(os.environ["SSH_KEY"])
-    client = paramiko.SSHClient()
-    client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
-    last_err = None
-    for attempt in range(retries):
-        try:
-            client.connect(
-                hostname=os.environ["VM_IP"],
-                username=os.environ["SSH_USER"],
-                pkey=key,
-                timeout=15,
-            )
-            return client
-        except Exception as e:
-            last_err = e
-            if attempt < retries - 1:
-                time.sleep(delay)
-    raise RuntimeError(f"SSH не удалось после {retries} попыток: {last_err}")
-
-
-def _run(client, cmd, timeout=120, check=True):
-    """Выполнить команду, вернуть (exit_code, stdout, stderr)."""
-    _, stdout, stderr = client.exec_command(cmd, timeout=timeout)
-    code = stdout.channel.recv_exit_status()
-    out = stdout.read().decode(errors="replace").strip()
-    err = stderr.read().decode(errors="replace").strip()
-    if check and code != 0:
-        raise RuntimeError(f"Ошибка (exit {code}):\n{cmd}\nstderr: {err}")
-    return code, out, err
-
-
-def _wait_apt_lock(client, attempts=20, delay=10):
-    """Ждать завершения cloud-init и убить авто-обновления. Ubuntu 22.04+."""
-    # Шаг 1: Ждём завершения cloud-init — он держит apt при первом старте VM
-    _run(client, "timeout 300 sudo cloud-init status --wait 2>/dev/null; true", check=False, timeout=310)
-    # Шаг 2: Mask (не просто disable) — systemd не сможет перезапустить
-    _run(client, "sudo systemctl mask unattended-upgrades apt-daily.service apt-daily-upgrade.service apt-daily.timer apt-daily-upgrade.timer 2>/dev/null; true", check=False)
-    _run(client, "sudo systemctl stop unattended-upgrades apt-daily.service apt-daily-upgrade.service 2>/dev/null; true", check=False)
-    # Шаг 3: Добить оставшиеся apt/dpkg процессы
-    _run(client, "sudo pkill -9 -x unattended-upgrades apt-get apt dpkg 2>/dev/null; true", check=False)
-    _run(client, "sudo kill -9 $(sudo lsof -t /var/lib/dpkg/lock-frontend 2>/dev/null) 2>/dev/null; true", check=False)
-    # Шаг 4: Убрать стейл-локи и починить dpkg
-    _run(client, "sudo rm -f /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock /var/cache/apt/archives/lock /var/lib/apt/lists/lock 2>/dev/null; true", check=False)
-    _run(client, "sudo dpkg --configure -a 2>/dev/null; true", check=False)
-    time.sleep(3)
-
-    locks = [
-        "/var/lib/dpkg/lock-frontend",
-        "/var/lib/dpkg/lock",
-        "/var/lib/apt/lists/lock",
-    ]
-    for i in range(attempts):
-        all_free = all(
-            _run(client, f"sudo flock -n {lock} true 2>/dev/null", check=False)[0] == 0
-            for lock in locks
-        )
-        if all_free:
-            return
-        # Повторить убийство процессов удерживающих lock
-        _run(client, "sudo pkill -9 -x apt-get apt dpkg 2>/dev/null; true", check=False)
-        _run(client, "sudo kill -9 $(sudo lsof -t /var/lib/dpkg/lock-frontend 2>/dev/null) 2>/dev/null; true", check=False)
-        if i < attempts - 1:
-            time.sleep(delay)
-    raise RuntimeError("apt lock занят слишком долго — проверьте процессы на ВМ")
-
-
-def install(event):
-    """Установить apt-пакеты. Идемпотентно — повторный запуск безопасен."""
-    packages = event.get("packages", [])
-    if not packages:
-        return {"status": "skipped", "reason": "packages list is empty"}
-
-    do_update = event.get("update", True)
-
-    client = _ssh_connect()
-    try:
-        _wait_apt_lock(client)
-
-        if do_update:
-            _run(client, "sudo DEBIAN_FRONTEND=noninteractive apt-get -o DPkg::Lock::Timeout=600 update -qq", timeout=420)
-
-        pkg_str = " ".join(packages)
-        _run(
-            client,
-            f"sudo DEBIAN_FRONTEND=noninteractive apt-get -o DPkg::Lock::Timeout=600 install -y -qq {pkg_str}",
-            timeout=300,
-        )
-
-        # Проверить что установилось
-        installed, missing = [], []
-        for pkg in packages:
-            code, _, _ = _run(
-                client,
-                f"dpkg -l {pkg} 2>/dev/null | grep -q '^ii'",
-                check=False,
-            )
-            (installed if code == 0 else missing).append(pkg)
-
-        return {
-            "status": "ok" if not missing else "partial",
-            "installed": installed,
-            "missing": missing,
-        }
-    finally:
-        client.close()
@@ -1,2 +0,0 @@
-paramiko
-# v6
@@ -1,43 +0,0 @@
-// 2026-03-25 — main.tf для примера с vApp + ВМ (Виртуальный датацентр Nubes).
-// Провайдер nubes. Sless-провайдер не нужен — пример чисто инфраструктурный.
-
-terraform {
-  required_providers {
-    nubes = {
-      source  = "terra.k8c.ru/nubes/nubes"
-      version = "5.0.51"
-    }
-    sless = {
-      source  = "terra.k8c.ru/naeel/sless"
-      version = "~> 0.1"
-    }
-  }
-}
-
-# ------------------------------------------------------------------
-# Переменные
-# ------------------------------------------------------------------
-
-variable "vm_public_key" {
-  type        = string
-  sensitive   = true
-  description = "Публичный SSH-ключ для ВМ. Приватный ключ: ~/terra/sless/examples/VM/vm_key"
-}
-
-variable "api_token" {
-  type        = string
-  sensitive   = true
-  description = "Nubes API token"
-}
-
-# ------------------------------------------------------------------
-# Провайдер
-# ------------------------------------------------------------------
-
-# API Dashboard (для Terraform-провайдеров): https://deck-api-test.ngcloud.ru/api/v1/index.cfm
-# UI облака (только браузер):               https://deck-test.ngcloud.ru/
-provider "nubes" {
-  api_token    = var.api_token
-  api_endpoint = "https://deck-api-test.ngcloud.ru/api/v1/index.cfm"
-  log_level    = "debug"   # none | info | debug, default = "none"
-}
@@ -1,18 +0,0 @@
-# 2026-03-29 — outputs.tf: результаты установки ПО на ВМ.
-# phase: Pending / Building / Running / Succeeded / Failed
-# message: JSON с деталями (что установлено) или traceback при ошибке
-
-output "install_packages_result" {
-  description = "Результат установки базовых пакетов"
-  value       = var.install_packages ? sless_job.install_packages[0].message : "skipped"
-}
-
-output "install_nginx_result" {
-  description = "Результат установки nginx"
-  value       = var.install_nginx ? sless_job.install_nginx[0].message : "skipped"
-}
-
-output "install_docker_result" {
-  description = "Результат установки Docker"
-  value       = var.install_docker ? sless_job.install_docker[0].message : "skipped"
-}
@@ -1,105 +0,0 @@
-# 2026-03-29 — sless.tf: провайдер sless и sless_job ресурсы для установки ПО на ВМ.
-#
-# Схема работы:
-#   1. terraform apply создаёт FunctionJob CR в k8s
-#   2. Провайдер загружает код из source_dir в S3
-#   3. Оператор собирает Docker-образ (kaniko) и запускает Job
-#   4. Job подключается к ВМ по SSH и устанавливает ПО
-#   5. terraform apply завершается: outputs содержат статус каждого шага
-#
-# Для повторного запуска: увеличь install_run_id в terraform.tfvars → terraform apply
-
-# ---------------------------------------------------------------------------
-# Провайдер
-# ---------------------------------------------------------------------------
-
-provider "sless" {
-  endpoint       = "https://sless.kube5s.ru"
-  token          = var.api_token # тот же JWT что и в provider "nubes"
-  nubes_endpoint = "https://deck-api-test.ngcloud.ru/api/v1/index.cfm"
-}
-
-# ---------------------------------------------------------------------------
-# Общие locals: SSH-параметры для подключения к ВМ
-# ---------------------------------------------------------------------------
-
-locals {
-  vm_ip = nubes_vc_vm_v3.vm.state_out_flat["externalConnect"]
-
-  ssh_env = {
-    VM_IP    = local.vm_ip
-    SSH_USER = "ubuntu"
-    SSH_KEY = file("${path.module}/vm_key")  # приватный ключ, созданный на шаге 2 (не хранится в git)
-  }
-}
-
-# ---------------------------------------------------------------------------
-# Job 1: базовые пакеты (jq, pip3 и др.)
-# ---------------------------------------------------------------------------
-
-resource "sless_job" "install_packages" {
-  count = var.install_packages ? 1 : 0
-
-  name       = "vm-install-packages"
-  runtime    = "python3.11"
-  entrypoint = "handler.install"
-  source_dir = "${path.module}/functions/install-packages"
-  memory_mb  = 128
-
-  env_vars = local.ssh_env
-  event_json = jsonencode({
-    packages = var.base_packages
-    update   = true
-  })
-
-  run_id           = var.install_run_id
-  wait_timeout_sec = 600
-
-  depends_on = [nubes_vc_vm_v3.vm]
-}
-
-# ---------------------------------------------------------------------------
-# Job 2: nginx
-# ---------------------------------------------------------------------------
-
-resource "sless_job" "install_nginx" {
-  count = var.install_nginx ? 1 : 0
-
-  name       = "vm-install-nginx"
-  runtime    = "python3.11"
-  entrypoint = "handler.install"
-  source_dir = "${path.module}/functions/install-nginx"
-  memory_mb  = 128
-
-  env_vars   = local.ssh_env
-  event_json = jsonencode({})
-
-  run_id           = var.install_run_id
-  wait_timeout_sec = 600
-
-  depends_on = [nubes_vc_vm_v3.vm, sless_job.install_packages]
-}
-
-# ---------------------------------------------------------------------------
-# Job 3: Docker CE
-# ---------------------------------------------------------------------------
-
-resource "sless_job" "install_docker" {
-  count = var.install_docker ? 1 : 0
-
-  name       = "vm-install-docker"
-  runtime    = "python3.11"
-  entrypoint = "handler.install"
-  source_dir = "${path.module}/functions/install-docker"
-  memory_mb  = 128
-
-  env_vars = local.ssh_env
-  event_json = jsonencode({
-    compose = true
-  })
-
-  run_id           = var.install_run_id
-  wait_timeout_sec = 900
-
-  depends_on = [nubes_vc_vm_v3.vm, sless_job.install_packages, sless_job.install_nginx]
-}
@@ -1,112 +0,0 @@
-# =============================================================================
-# terraform.tfvars.template — шаблон конфигурации примера «ВМ в Nubes vDC»
-# =============================================================================
-#
-# Скопируйте этот файл в terraform.tfvars и заполните все значения:
-#
-#   cp terraform.tfvars.template terraform.tfvars
-#
-# terraform.tfvars НЕ коммитится в git (защищён .gitignore) —
-# он содержит секретные данные (API-токен, SSH-ключ).
-# =============================================================================
-
-
-# =============================================================================
-# 1. API-ТОКЕН
-# =============================================================================
-#
-# Один токен для обоих провайдеров: nubes (облако) и sless (serverless).
-#
-# Где взять:
-#   Личный Кабинет Nubes → правый верхний угол → «Профиль» → «API-токены»
-#   → кнопка «Создать токен» → скопируйте JWT-строку целиком.
-#
-# Токен выглядит так: eyJhbGciOiJS...длинная строка...
-# Вставьте в кавычки целиком, не разбивая на строки.
-#
-api_token = "ВСТАВИТЬ_API_ТОКЕН"
-
-
-# =============================================================================
-# 2. SSH-КЛЮЧ ДЛЯ ВМ
-# =============================================================================
-#
-# Публичный ключ прописывается в ВМ при создании.
-# Приватный ключ нужен для SSH-подключения к ВМ.
-#
-# Как сгенерировать:
-#   ssh-keygen -t ed25519 -f ./vm_key -N "" -C "sless-demo-vm"
-#   # Создаст два файла: vm_key (приватный) и vm_key.pub (публичный)
-#
-# vm_key.pub уже есть в папке — скопируйте его содержимое сюда.
-# Строка выглядит так: ssh-ed25519 AAAA... имя-ключа
-#
-vm_public_key = "ВСТАВИТЬ_ПУБЛИЧНЫЙ_SSH_КЛЮЧ"
-
-
-# =============================================================================
-# 3. UUID СЕРВИСОВ NUBES (вdc_uid и nsxt_uid)
-# =============================================================================
-#
-# Где взять:
-#   Личный Кабинет → «Мои сервисы» → найдите нужный сервис → раздел
-#   «Параметры инстанса» или «Технические параметры» → UUID.
-#
-#   vdc_uid  — это UUID услуги «Виртуальный датацентр (vDC)»
-#              Пример раздела ЛК: Мои сервисы → vDC → [ваш vDC] → UUID
-#
-#   nsxt_uid — это UUID услуги «Сетевой шлюз периметра (Edge)»
-#              Пример раздела ЛК: Мои сервисы → Edge → [ваш Edge] → UUID
-#
-# Формат: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  (UUID v4)
-#
-# ВАЖНО: эти значения не изменяются после создания vApp.
-# После первого terraform apply менять их нельзя — сломает state.
-#
-vdc_uid  = "ВСТАВИТЬ_UUID_VDC"
-nsxt_uid = "ВСТАВИТЬ_UUID_NSXT"
-
-
-# =============================================================================
-# 4. ФЛАГИ УСТАНОВКИ ПО НА ВМ
-# =============================================================================
-#
-# Что устанавливать при terraform apply.
-# Установка выполняется через serverless-джобы (sless_job) по SSH на ВМ.
-# Каждый флаг — отдельный джоб, они выполняются независимо.
-#
-# true  = установить
-# false = не устанавливать (ресурс не создаётся вовсе)
-#
-install_packages = true   # базовые apt-пакеты из списка base_packages ниже
-install_nginx    = true   # nginx (веб-сервер)
-install_docker   = true   # Docker CE + docker-compose-plugin
-
-
-# =============================================================================
-# 5. СПИСОК БАЗОВЫХ ПАКЕТОВ
-# =============================================================================
-#
-# Эти пакеты устанавливаются когда install_packages = true.
-# Любые стандартные apt-пакеты Ubuntu 22.04.
-#
-# Как изменить список:
-#   - Добавьте пакет: base_packages = ["jq", "htop", "curl", "git"]
-#   - Удалите пакет: уберите его из списка
-#   - После изменения: увеличьте install_run_id (см. ниже) и terraform apply
-#
-base_packages = ["jq", "python3-pip", "htop", "unzip"]
-
-
-# =============================================================================
-# 6. RUN_ID — триггер повторного запуска джобов
-# =============================================================================
-#
-# sless_job — это разовые джобы (k8s Job). Terraform не перезапускает их
-# автоматически если код не изменился. Чтобы запустить ВСЕ install-джобы
-# заново (например, после изменения base_packages) — увеличьте это число на 1
-# и выполните terraform apply.
-#
-# Например: было install_run_id = 3 → стало install_run_id = 4 → apply
-#
-install_run_id = 1
@@ -1,28 +0,0 @@
-// 2026-03-25 — vapp.tf: виртуальный каталог ВМ (vApp) в Nubes vDC.
-// nubes_vapp — контейнер для ВМ внутри Виртуального датацентра.
-// Обязательные поля: vdc_uid, nsxt_uid, vapp_name, resource_name.
-
-resource "nubes_vapp" "vapp" {
-  resource_name = "vm-sless-vapp"
-  vapp_name     = "vapp-sless"                # Уникальное в рамках организации. Не изменяется после создания.
-  vdc_uid       = var.vdc_uid                 # UUID Услуги «Виртуальный датацентр (vDC)». В terraform.tfvars.
-  nsxt_uid      = var.nsxt_uid                # UUID Услуги «Сетевой шлюз периметра (Edge)». В terraform.tfvars.
-
-  adopt_existing_on_create = true
-  operation_timeout        = "15m"
-
-  # ВАЖНО: delete без предварительного suspend завершается ошибкой
-  # "Невозможно выполнить операцию удаления услуги. Услуга не остановлена"
-  # suspend_on_destroy гарантирует правильный порядок: suspend → delete.
-  suspend_on_destroy = true
-}
-
-output "vapp_id" {
-  value       = nubes_vapp.vapp.id
-  description = "ID созданного vApp (используется как vapp_uid при создании ВМ)"
-}
-
-output "vapp_state" {
-  value       = nubes_vapp.vapp.state_out_flat
-  description = "Плоский state vApp — адреса, статусы сети и т.д."
-}
@@ -1,51 +0,0 @@
-# 2026-03-29 — variables.tf: переменные для sless и установки ПО на ВМ.
-# Переменные nubes (api_token, vm_public_key) остаются в main.tf.
-# sless использует тот же api_token — отдельной переменной не нужно.
-
-# ---- Флаги: что устанавливать на ВМ --------------------------------------
-
-variable "install_packages" {
-  type        = bool
-  default     = true
-  description = "Установить базовые apt-пакеты (jq и др.)"
-}
-
-variable "install_nginx" {
-  type        = bool
-  default     = false
-  description = "Установить nginx"
-}
-
-variable "install_docker" {
-  type        = bool
-  default     = false
-  description = "Установить Docker CE + docker-compose-plugin"
-}
-
-# ---- Параметры ------------------------------------------------------------
-
-variable "base_packages" {
-  type        = list(string)
-  default     = ["jq", "python3-pip", "htop", "unzip"]
-  description = "Список apt-пакетов для install-packages"
-}
-
-variable "install_run_id" {
-  type        = number
-  default     = 1
-  description = "Увеличь на 1 чтобы запустить все install-джобы заново"
-}
-
-# ---- Идентификаторы сервисов Nubes ----------------------------------------
-# Берутся из Личного Кабинета → «Мои сервисы» → нужный сервис → параметры инстанса.
-# Не изменяются после создания vApp.
-
-variable "vdc_uid" {
-  type        = string
-  description = "UUID услуги «Виртуальный датацентр (vDC)». Личный Кабинет → Мои сервисы → vDC → UUID."
-}
-
-variable "nsxt_uid" {
-  type        = string
-  description = "UUID услуги «Сетевой шлюз периметра (Edge / NSX-T)». Личный Кабинет → Мои сервисы → Edge → UUID."
-}
@@ -1,37 +0,0 @@
-// 2026-03-25 — vm.tf: виртуальная машина (nubes_vc_vm_v3) внутри vApp.
-// Зависит от nubes_vapp.vapp — создаётся после vApp.
-// image_vm, vapp_uid, user_public_key не изменяются после создания.
-
-resource "nubes_vc_vm_v3" "vm" {
-  resource_name = "vm-sless-1"
-  vm_name       = "web02" # Имя ВМ в Nubes vCD. Не изменяется после создания.
-  # Определяет имя NSX-T IP Set: {vapp_name}-{vm_name}
-
-  vapp_uid = nubes_vapp.vapp.id # ссылка на vApp. Не изменяется после создания.
-  image_vm = "Ubuntu_22-20G"    # Не изменяется после создания.
-  #   image_vm      = "Ubuntu 22.04 LTS"              # Не изменяется после создания.
-  ip_space_name = "internet-ipv4-v1"
-
-  user_login      = "ubuntu"
-  user_public_key = var.vm_public_key # задаётся в terraform.tfvars
-
-  vm_cpu  = 2
-  vm_ram  = 2  # GB
-  vm_disk = 20 # GB
-
-  adopt_existing_on_create = true
-  operation_timeout        = "15m"
-
-  # delete без предварительного suspend завершается ошибкой (аналогично vApp).
-  suspend_on_destroy = true
-}
-
-output "vm_id" {
-  value       = nubes_vc_vm_v3.vm.id
-  description = "ID созданной ВМ"
-}
-
-output "vm_state" {
-  value       = nubes_vc_vm_v3.vm.state_out_flat
-  description = "Плоский state ВМ — IP-адреса, статус и т.д."
-}
@@ -1,931 +0,0 @@
-#!/usr/bin/env bash
-# 2026-03-30 — vm_stress_test.sh (v2 — READ-ONLY)
-# Автономный READ-ONLY stress/chaos тест для examples/VM.
-#
-# ⛔⛔⛔ КРИТИЧЕСКОЕ ПРАВИЛО — ДЛЯ AI-АГЕНТОВ И ЛЮДЕЙ ⛔⛔⛔
-#
-# Этот скрипт НИКОГДА НЕ МОДИФИЦИРУЕТ terraform.tfvars и НИКАКИЕ ДРУГИЕ ФАЙЛЫ.
-# Все переопределения переменных — ТОЛЬКО через terraform CLI опцию -var.
-# Файл terraform.tfvars ЧИТАЕТСЯ, но НИКОГДА НЕ ПЕРЕЗАПИСЫВАЕТСЯ.
-#
-# ЗАПРЕЩЕНО:
-#   - Редактировать этот скрипт
-#   - Редактировать terraform.tfvars
-#   - Редактировать любые .tf файлы
-#   - Запускать terraform напрямую — только через этот скрипт
-#
-# ПРИЧИНА: предыдущая версия скрипта уничтожила terraform.tfvars
-# через write_tfvars() — потерян JWT-токен api_token. Это НЕДОПУСТИМО.
-#
-# ФАЗЫ:
-#   1  BASELINE         — apply с текущим tfvars (packages + nginx + docker)
-#   2  IDEMPOTENT       — повторный plan → "No changes"
-#   3  PARTIAL_DISABLE  — apply с -var install_nginx=false -var install_docker=false
-#   4  PARTIAL_ENABLE   — apply с -var install_nginx=true -var install_docker=true (run_id+1)
-#   5  REORDER_PACKAGES — apply с -var 'base_packages=["htop","jq"]' (run_id+1)
-#   6  MANUAL_PURGE     — удалить пакеты с VM по SSH → apply (run_id+1)
-#   7  DESTROY          — terraform destroy → VM уходит в suspend
-#   8  RESURRECT        — apply после destroy → VM просыпается
-#   9  STRESS_CYCLES    — N подряд destroy/apply циклов
-#  10  FINAL_SANITY     — проверить доступность VM и пакеты
-#
-# ЗАПУСК:
-#   cd ~/terra/sless/examples/VM
-#   bash vm_stress_test.sh 2>&1 | tee /tmp/vm_stress_$(date +%Y%m%d_%H%M).log
-#
-# ПАРАМЕТРЫ (env):
-#   STRESS_CYCLES=2   — количество destroy/apply циклов в фазе 9 (default: 2)
-#   SKIP_DESTROY=1    — пропустить фазы 7-9 (для быстрого прогона)
-#
-# АНАЛИЗ РЕЗУЛЬТАТОВ:
-#   grep -E '\[(PASS|FAIL|SKIP)\]' /tmp/vm_stress.log
-#   Итоговая сводка печатается в конце лога.
-#
-# ТРЕБОВАНИЯ: terraform, ssh, python3 — всё на VM naeel@5.172.178.213
-
-set -uo pipefail
-
-# ── CONFIG ────────────────────────────────────────────────────────────────────
-
-SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
-cd "$SCRIPT_DIR"
-
-VM_KEY="$SCRIPT_DIR/vm_key"
-STRESS_CYCLES="${STRESS_CYCLES:-2}"
-SKIP_DESTROY="${SKIP_DESTROY:-0}"
-
-# Читаем текущий run_id из terraform.tfvars (ТОЛЬКО ЧТЕНИЕ, не запись)
-RUN_ID=$(grep 'install_run_id' terraform.tfvars | grep -oP '\d+' | head -1)
-
-# ── СТАТИСТИКА ────────────────────────────────────────────────────────────────
-
-PASS=0; FAIL=0; SKIP=0
-PHASE_RESULTS=()
-START_TIME=$SECONDS
-
-# ── ЦВЕТА ─────────────────────────────────────────────────────────────────────
-
-GREEN='\033[0;32m'; RED='\033[0;31m'; YELLOW='\033[1;33m'
-CYAN='\033[0;36m'; BOLD='\033[1m'; RESET='\033[0m'
-
-# ── HELPERS ───────────────────────────────────────────────────────────────────
-
-pass()    { echo -e "  ${GREEN}[PASS]${RESET} $1"; ((PASS++)); }
-fail()    { echo -e "  ${RED}[FAIL]${RESET} $1"; ((FAIL++)); }
-skip()    { echo -e "  ${YELLOW}[SKIP]${RESET} $1"; ((SKIP++)); }
-info()    { echo -e "  ${CYAN}[INFO]${RESET} $1"; }
-warn()    { echo -e "  ${YELLOW}[WARN]${RESET} $1"; }
-
-phase_header() {
-    local num="$1" name="$2"
-    echo ""
-    echo -e "${BOLD}${CYAN}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${RESET}"
-    echo -e "${BOLD}${CYAN}  ФАЗА $num: $name${RESET}"
-    echo -e "${BOLD}${CYAN}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${RESET}"
-    echo -e "  ${CYAN}[TIME]${RESET} $(date '+%H:%M:%S')"
-}
-
-phase_result() {
-    local name="$1" result="$2"
-    PHASE_RESULTS+=("$name:$result")
-    echo -e "  ${CYAN}[PHASE]${RESET} $name → ${result}"
-}
-
-# ── TERRAFORM HELPERS ─────────────────────────────────────────────────────────
-# ⛔ НЕ ТРОГАЕМ terraform.tfvars. Переопределения — ТОЛЬКО через -var.
-# terraform.tfvars подхватывается автоматически (лежит в рабочей директории).
-# Доп. -var аргументы передаются во все tf_* функции и ПЕРЕОПРЕДЕЛЯЮТ tfvars.
-
-# tf_apply: apply с retry при сетевых ошибках.
-# Аргументы: любые доп. -var (опционально).
-# Пример: tf_apply -var install_nginx=false -var install_docker=false
-tf_apply() {
-    local attempt=1 max=3
-    while [[ $attempt -le $max ]]; do
-        info "terraform apply (попытка $attempt/$max)..."
-        if terraform apply -auto-approve -input=false -no-color "$@" 2>&1 | tee /tmp/vm_tf_apply.log; then
-            return 0
-        fi
-        if grep -Eiq 'TLS handshake timeout|unexpected EOF|i/o timeout|context deadline|Client\.Timeout' /tmp/vm_tf_apply.log && [[ $attempt -lt $max ]]; then
-            warn "сетевой сбой, retry через $((attempt * 5))s..."
-            sleep $((attempt * 5))
-            ((attempt++))
-            continue
-        fi
-        return 1
-    done
-    return 1
-}
-
-# tf_destroy: destroy с retry.
-# Аргументы: любые доп. -var (опционально).
-tf_destroy() {
-    local attempt=1 max=3
-    while [[ $attempt -le $max ]]; do
-        info "terraform destroy (попытка $attempt/$max)..."
-        if terraform destroy -auto-approve -input=false -no-color "$@" 2>&1 | tee /tmp/vm_tf_destroy.log; then
-            return 0
-        fi
-        if grep -Eiq 'TLS handshake timeout|unexpected EOF|i/o timeout|context deadline|Client\.Timeout' /tmp/vm_tf_destroy.log && [[ $attempt -lt $max ]]; then
-            warn "сетевой сбой, retry через $((attempt * 5))s..."
-            sleep $((attempt * 5))
-            ((attempt++))
-            continue
-        fi
-        return 1
-    done
-    return 1
-}
-
-# tf_plan_no_changes: проверить plan → "No changes".
-# Аргументы: любые доп. -var (опционально).
-tf_plan_no_changes() {
-    terraform plan -input=false -no-color "$@" 2>&1 | tee /tmp/vm_tf_plan.log
-    grep -q 'No changes' /tmp/vm_tf_plan.log
-}
-
-# tf_state_count: количество ресурсов в state.
-tf_state_count() {
-    terraform state list 2>/dev/null | wc -l
-}
-
-# next_run_id: инкрементировать внутренний счётчик RUN_ID и вернуть новое значение.
-# Используется для -var install_run_id=N чтобы форсировать пересоздание jobs.
-next_run_id() {
-    RUN_ID=$((RUN_ID + 1))
-    echo "$RUN_ID"
-}
-
-# ── VM SSH HELPERS ────────────────────────────────────────────────────────────
-
-# get_vm_ip: получить внешний IP VM из terraform output.
-get_vm_ip() {
-    terraform output -json vm_state 2>/dev/null \
-        | python3 -c "import sys,json; d=json.load(sys.stdin); print(d.get('externalConnect',''))" 2>/dev/null
-}
-
-# vm_ssh: выполнить команду на VM. Возвращает exit code команды.
-vm_ssh() {
-    local ip="$1"; shift
-    ssh -i "$VM_KEY" -o StrictHostKeyChecking=no -o ConnectTimeout=15 \
-        -o ServerAliveInterval=5 -o ServerAliveCountMax=3 \
-        "ubuntu@$ip" "$@"
-}
-
-# vm_alive: проверить доступность VM по SSH.
-vm_alive() {
-    local ip="$1"
-    vm_ssh "$ip" 'echo alive' &>/dev/null
-}
-
-# vm_wait_alive: ждать пока VM ответит по SSH (до timeout_sec).
-vm_wait_alive() {
-    local ip="$1" timeout_sec="${2:-120}"
-    local deadline=$((SECONDS + timeout_sec))
-    while [[ $SECONDS -lt $deadline ]]; do
-        if vm_alive "$ip"; then return 0; fi
-        sleep 10
-    done
-    return 1
-}
-
-# vm_check_package: проверить что пакет установлен.
-vm_check_package() {
-    local ip="$1" pkg="$2"
-    vm_ssh "$ip" "dpkg -l $pkg 2>/dev/null | grep -q '^ii'" 2>/dev/null
-}
-
-# vm_check_binary: проверить что бинарник доступен.
-vm_check_binary() {
-    local ip="$1" bin="$2"
-    vm_ssh "$ip" "command -v $bin" &>/dev/null
-}
-
-# vm_wait_binary: ждать пока бинарник появится на VM (sless_job работает асинхронно).
-# Нужен потому что sless_job запускает kubernetes Job, который сначала собирает образ,
-# затем стартует pod, и только потом SSH-устанавливает пакеты на VM — это занимает 1-3 мин.
-vm_wait_binary() {
-    local ip="$1" bin="$2" timeout_sec="${3:-180}"
-    local deadline=$((SECONDS + timeout_sec))
-    info "жду появления '$bin' на VM (до ${timeout_sec}s)..."
-    while [[ $SECONDS -lt $deadline ]]; do
-        if vm_check_binary "$ip" "$bin"; then return 0; fi
-        sleep 15
-    done
-    return 1
-}
-
-# vm_purge_all: удалить все установленные пакеты с VM.
-vm_purge_all() {
-    local ip="$1"
-    info "удаляю пакеты с VM $ip..."
-    vm_ssh "$ip" 'sudo systemctl stop nginx docker 2>/dev/null; sudo apt-get purge -y jq python3-pip htop unzip nginx docker-ce docker-ce-cli containerd.io docker-compose-plugin 2>/dev/null; sudo apt-get autoremove -y 2>/dev/null; sudo rm -rf /var/lib/docker /var/lib/containerd; echo purge_done' 2>/dev/null
-}
-
-# ══════════════════════════════════════════════════════════════════════════════
-# ФАЗА 1: BASELINE — apply с текущим tfvars (всё включено)
-# Используем -var install_run_id=N чтобы гарантировать свежий запуск.
-# terraform.tfvars НЕ ТРОГАЕМ — берём как есть.
-# ══════════════════════════════════════════════════════════════════════════════
-
-phase_1_baseline() {
-    phase_header 1 "BASELINE — apply с полным набором"
-
-    local rid
-    rid=$(next_run_id)
-
-    # Все флаги = true (как в tfvars), но run_id инкрементирован
-    if tf_apply \
-        -var "install_packages=true" \
-        -var "install_nginx=true" \
-        -var "install_docker=true" \
-        -var "install_run_id=$rid"; then
-        pass "1.1 terraform apply завершился успешно"
-    else
-        fail "1.1 terraform apply упал"
-        phase_result "BASELINE" "FAIL"
-        return 1
-    fi
-
-    # Проверить количество ресурсов
-    local count
-    count=$(tf_state_count)
-    if [[ $count -ge 5 ]]; then
-        pass "1.2 state содержит $count ресурсов (ожидали ≥5)"
-    else
-        fail "1.2 state содержит $count ресурсов (ожидали ≥5)"
-    fi
-
-    # Проверить outputs
-    local out
-    out=$(terraform output -json 2>/dev/null)
-
-    if echo "$out" | python3 -c "import sys,json; d=json.load(sys.stdin); assert 'ok' in d['install_packages_result']['value'] or 'already' in d['install_packages_result']['value']" 2>/dev/null; then
-        pass "1.3 install_packages_result содержит ok/already_installed"
-    else
-        fail "1.3 install_packages_result не содержит ok"
-    fi
-
-    if echo "$out" | python3 -c "import sys,json; d=json.load(sys.stdin); v=d['install_nginx_result']['value']; assert 'ok' in v or 'already' in v" 2>/dev/null; then
-        pass "1.4 install_nginx_result содержит ok/already"
-    else
-        fail "1.4 install_nginx_result не содержит ok"
-    fi
-
-    if echo "$out" | python3 -c "import sys,json; d=json.load(sys.stdin); v=d['install_docker_result']['value']; assert 'ok' in v or 'already' in v" 2>/dev/null; then
-        pass "1.5 install_docker_result содержит ok/already"
-    else
-        fail "1.5 install_docker_result не содержит ok"
-    fi
-
-    # Проверить VM по SSH
-    local ip
-    ip=$(get_vm_ip)
-    if [[ -n "$ip" ]] && vm_alive "$ip"; then
-        pass "1.6 VM $ip доступна по SSH"
-    else
-        fail "1.6 VM не доступна по SSH (ip=$ip)"
-    fi
-
-    phase_result "BASELINE" "PASS"
-}
-
-# ══════════════════════════════════════════════════════════════════════════════
-# ФАЗА 2: IDEMPOTENT — повторный apply с теми же аргументами → 0 changed
-# Используем apply (не plan) — это надёжнее: некоторые sless-провайдеры показывают
-# ложный drift в plan, но apply при этом возвращает 0 changed. Apply — canonical way.
-# ══════════════════════════════════════════════════════════════════════════════
-
-phase_2_idempotent() {
-    phase_header 2 "IDEMPOTENT — повторный apply без изменений"
-
-    # Тот же run_id что применялся в фазе 1 → apply должен вернуть 0 changed
-    # sless_job — эфемерный ресурс, каждый apply пересоздаёт job-ресурсы (add+destroy).
-    # Идемпотентность = "0 changed" (ноль in-place изменений), а не "0 add/destroy".
-    # VM и vApp не должны изменяться никогда.
-    if tf_apply \
-        -var "install_packages=true" \
-        -var "install_nginx=true" \
-        -var "install_docker=true" \
-        -var "install_run_id=$RUN_ID"; then
-        if grep -q ', 0 changed,' /tmp/vm_tf_apply.log; then
-            pass "2.1 повторный apply → 0 changed (sless_job пересоздан — ожидаемо)"
-            grep -E 'Resources:' /tmp/vm_tf_apply.log | tail -1 | while read -r line; do
-                info "  $line"
-            done
-        else
-            fail "2.1 повторный apply изменил persistent ресурсы (ожидали 0 changed)"
-            grep -E 'added|changed|destroyed' /tmp/vm_tf_apply.log | tail -3 | while read -r line; do
-                info "  $line"
-            done
-        fi
-    else
-        fail "2.1 повторный apply упал"
-    fi
-
-    phase_result "IDEMPOTENT" "PASS"
-}
-
-# ══════════════════════════════════════════════════════════════════════════════
-# ФАЗА 3: PARTIAL_DISABLE — выключить nginx + docker
-# Используем -var install_nginx=false -var install_docker=false
-# terraform.tfvars по-прежнему НЕ ТРОГАЕМ.
-# ══════════════════════════════════════════════════════════════════════════════
-
-phase_3_partial_disable() {
-    phase_header 3 "PARTIAL_DISABLE — выключить nginx + docker"
-
-    if tf_apply \
-        -var "install_packages=true" \
-        -var "install_nginx=false" \
-        -var "install_docker=false" \
-        -var "install_run_id=$RUN_ID"; then
-        pass "3.1 apply с partial disable завершился"
-    else
-        fail "3.1 apply с partial disable упал"
-        phase_result "PARTIAL_DISABLE" "FAIL"
-        return 1
-    fi
-
-    # Проверить что nginx и docker job пропали из state
-    local state_list
-    state_list=$(terraform state list 2>/dev/null)
-
-    if echo "$state_list" | grep -q 'install_nginx'; then
-        fail "3.2 install_nginx всё ещё в state"
-    else
-        pass "3.2 install_nginx убран из state"
-    fi
-
-    if echo "$state_list" | grep -q 'install_docker'; then
-        fail "3.3 install_docker всё ещё в state"
-    else
-        pass "3.3 install_docker убран из state"
-    fi
-
-    if echo "$state_list" | grep -q 'install_packages'; then
-        pass "3.4 install_packages остался в state"
-    else
-        fail "3.4 install_packages пропал из state"
-    fi
-
-    # Проверить outputs
-    local nginx_out docker_out
-    nginx_out=$(terraform output -raw install_nginx_result 2>/dev/null)
-    docker_out=$(terraform output -raw install_docker_result 2>/dev/null)
-
-    if [[ "$nginx_out" == "skipped" ]]; then
-        pass "3.5 install_nginx_result = skipped"
-    else
-        fail "3.5 install_nginx_result = '$nginx_out' (ожидали skipped)"
-    fi
-
-    if [[ "$docker_out" == "skipped" ]]; then
-        pass "3.6 install_docker_result = skipped"
-    else
-        fail "3.6 install_docker_result = '$docker_out' (ожидали skipped)"
-    fi
-
-    phase_result "PARTIAL_DISABLE" "PASS"
-}
-
-# ══════════════════════════════════════════════════════════════════════════════
-# ФАЗА 4: PARTIAL_ENABLE — включить обратно всё
-# Инкрементируем run_id чтобы jobs пересоздались.
-# ══════════════════════════════════════════════════════════════════════════════
-
-phase_4_partial_enable() {
-    phase_header 4 "PARTIAL_ENABLE — включить обратно всё"
-
-    local rid
-    rid=$(next_run_id)
-
-    if tf_apply \
-        -var "install_packages=true" \
-        -var "install_nginx=true" \
-        -var "install_docker=true" \
-        -var "install_run_id=$rid"; then
-        pass "4.1 apply с полным набором завершился"
-    else
-        fail "4.1 apply с полным набором упал"
-        phase_result "PARTIAL_ENABLE" "FAIL"
-        return 1
-    fi
-
-    local count
-    count=$(tf_state_count)
-    if [[ $count -ge 5 ]]; then
-        pass "4.2 state содержит $count ресурсов (ожидали ≥5)"
-    else
-        fail "4.2 state содержит $count ресурсов (ожидали ≥5)"
-    fi
-
-    phase_result "PARTIAL_ENABLE" "PASS"
-}
-
-# ══════════════════════════════════════════════════════════════════════════════
-# ФАЗА 5: REORDER_PACKAGES — изменить порядок и состав base_packages
-# Через -var 'base_packages=["htop","jq"]' — terraform.tfvars не трогаем.
-# ══════════════════════════════════════════════════════════════════════════════
-
-phase_5_reorder() {
-    phase_header 5 "REORDER_PACKAGES — изменить порядок и состав пакетов"
-
-    local rid
-    rid=$(next_run_id)
-
-    # Сокращённый набор пакетов через -var
-    if tf_apply \
-        -var "install_packages=true" \
-        -var "install_nginx=true" \
-        -var "install_docker=true" \
-        -var "install_run_id=$rid" \
-        -var 'base_packages=["htop","jq"]'; then
-        pass "5.1 apply с изменённым набором пакетов завершился"
-    else
-        fail "5.1 apply с изменённым набором пакетов упал"
-        phase_result "REORDER_PACKAGES" "FAIL"
-        return 1
-    fi
-
-    # Проверить output
-    local pkg_out
-    pkg_out=$(terraform output -raw install_packages_result 2>/dev/null)
-    if echo "$pkg_out" | grep -qE '"status"|ok|already'; then
-        pass "5.2 install_packages вернул ожидаемый результат"
-    else
-        fail "5.2 install_packages output неожиданный: $pkg_out"
-    fi
-
-    # Вернуть полный набор пакетов
-    rid=$(next_run_id)
-    tf_apply \
-        -var "install_packages=true" \
-        -var "install_nginx=true" \
-        -var "install_docker=true" \
-        -var "install_run_id=$rid" \
-        || warn "5.3 восстановление полного набора не удалось"
-
-    phase_result "REORDER_PACKAGES" "PASS"
-}
-
-# ══════════════════════════════════════════════════════════════════════════════
-# ФАЗА 6: MANUAL_PURGE — удалить пакеты с VM вручную, заново установить
-# ══════════════════════════════════════════════════════════════════════════════
-
-phase_6_manual_purge() {
-    phase_header 6 "MANUAL_PURGE — удалить пакеты с VM, заново установить"
-
-    local ip
-    ip=$(get_vm_ip)
-    if [[ -z "$ip" ]]; then
-        fail "6.0 не удалось получить IP VM"
-        phase_result "MANUAL_PURGE" "FAIL"
-        return 1
-    fi
-
-    # Удалить всё с VM
-    vm_purge_all "$ip"
-
-    # Проверить что пакеты действительно удалены
-    if vm_check_binary "$ip" "docker"; then
-        fail "6.1 docker всё ещё на VM после purge"
-    else
-        pass "6.1 docker удалён с VM"
-    fi
-
-    if vm_check_binary "$ip" "nginx"; then
-        fail "6.2 nginx всё ещё на VM после purge"
-    else
-        pass "6.2 nginx удалён с VM"
-    fi
-
-    if vm_check_binary "$ip" "jq"; then
-        fail "6.3 jq всё ещё на VM после purge"
-    else
-        pass "6.3 jq удалён с VM"
-    fi
-
-    # Пересоздать jobs (bump run_id)
-    local rid
-    rid=$(next_run_id)
-
-    info "запускаю переустановку через sless_job..."
-    if tf_apply \
-        -var "install_packages=true" \
-        -var "install_nginx=true" \
-        -var "install_docker=true" \
-        -var "install_run_id=$rid"; then
-        pass "6.4 apply после purge завершился"
-    else
-        fail "6.4 apply после purge упал"
-        phase_result "MANUAL_PURGE" "FAIL"
-        return 1
-    fi
-
-    # Ждать пока sless_job отработает: docker самый долгий (k8s Job + образ + apt-install ~200MB).
-    # docker-ce требует до 5 минут на первой установке — ставим 360s.
-    if vm_wait_binary "$ip" "docker" 360; then
-        pass "6.5 docker установлен заново"
-    else
-        fail "6.5 docker НЕ установлен после re-apply (таймаут 360s)"
-    fi
-
-    if vm_wait_binary "$ip" "nginx" 240; then
-        pass "6.6 nginx установлен заново"
-    else
-        fail "6.6 nginx НЕ установлен после re-apply (таймаут 240s)"
-    fi
-
-    if vm_check_binary "$ip" "jq"; then
-        pass "6.7 jq установлен заново"
-    else
-        fail "6.7 jq НЕ установлен после re-apply"
-    fi
-
-    phase_result "MANUAL_PURGE" "PASS"
-}
-
-# ══════════════════════════════════════════════════════════════════════════════
-# ФАЗА 7: DESTROY — terraform destroy, VM уходит в suspend
-# ══════════════════════════════════════════════════════════════════════════════
-
-phase_7_destroy() {
-    phase_header 7 "DESTROY — terraform destroy → VM в suspend"
-
-    local ip
-    ip=$(get_vm_ip)
-
-    if tf_destroy; then
-        pass "7.1 terraform destroy завершился"
-    else
-        fail "7.1 terraform destroy упал"
-        phase_result "DESTROY" "FAIL"
-        return 1
-    fi
-
-    # State должен быть пуст
-    local count
-    count=$(tf_state_count)
-    if [[ $count -eq 0 ]]; then
-        pass "7.2 state пуст ($count ресурсов)"
-    else
-        fail "7.2 state не пуст ($count ресурсов)"
-    fi
-
-    # VM не должна отвечать по SSH
-    if [[ -n "$ip" ]]; then
-        info "проверяю что VM $ip недоступна..."
-        if vm_alive "$ip"; then
-            fail "7.3 VM $ip всё ещё отвечает по SSH после destroy"
-        else
-            pass "7.3 VM $ip не отвечает по SSH (suspend подтверждён)"
-        fi
-    else
-        skip "7.3 IP VM неизвестен, пропускаю SSH-проверку"
-    fi
-
-    phase_result "DESTROY" "PASS"
-}
-
-# ══════════════════════════════════════════════════════════════════════════════
-# ФАЗА 8: RESURRECT — apply после destroy, VM просыпается
-# Используем текущий run_id — terraform.tfvars НЕ ТРОГАЕМ.
-# ══════════════════════════════════════════════════════════════════════════════
-
-phase_8_resurrect() {
-    phase_header 8 "RESURRECT — apply после destroy"
-
-    local rid
-    rid=$(next_run_id)
-
-    if tf_apply \
-        -var "install_packages=true" \
-        -var "install_nginx=true" \
-        -var "install_docker=true" \
-        -var "install_run_id=$rid"; then
-        pass "8.1 apply после destroy завершился"
-    else
-        fail "8.1 apply после destroy упал"
-        phase_result "RESURRECT" "FAIL"
-        return 1
-    fi
-
-    local count
-    count=$(tf_state_count)
-    if [[ $count -ge 5 ]]; then
-        pass "8.2 state содержит $count ресурсов"
-    else
-        fail "8.2 state содержит $count ресурсов (ожидали ≥5)"
-    fi
-
-    # Проверить VM
-    local ip
-    ip=$(get_vm_ip)
-    if [[ -n "$ip" ]] && vm_alive "$ip"; then
-        pass "8.3 VM $ip доступна по SSH после resurrect"
-    else
-        # VM может ещё просыпаться — ждём
-        info "VM не отвечает, жду до 120s..."
-        if vm_wait_alive "$ip" 120; then
-            pass "8.3 VM $ip доступна по SSH после ожидания"
-        else
-            fail "8.3 VM $ip не доступна по SSH через 120s"
-        fi
-    fi
-
-    # Проверить пакеты
-    if [[ -n "$ip" ]] && vm_alive "$ip"; then
-        if vm_check_binary "$ip" "jq"; then
-            pass "8.4 jq установлен после resurrect"
-        else
-            fail "8.4 jq НЕ установлен после resurrect"
-        fi
-
-        if vm_check_binary "$ip" "nginx"; then
-            pass "8.5 nginx установлен после resurrect"
-        else
-            fail "8.5 nginx НЕ установлен после resurrect"
-        fi
-
-        if vm_check_binary "$ip" "docker"; then
-            pass "8.6 docker установлен после resurrect"
-        else
-            fail "8.6 docker НЕ установлен после resurrect"
-        fi
-    fi
-
-    phase_result "RESURRECT" "PASS"
-}
-
-# ══════════════════════════════════════════════════════════════════════════════
-# ФАЗА 9: STRESS_CYCLES — N destroy/apply циклов подряд
-# ══════════════════════════════════════════════════════════════════════════════
-
-phase_9_stress() {
-    phase_header 9 "STRESS_CYCLES — $STRESS_CYCLES циклов destroy/apply"
-
-    local i rid
-    for i in $(seq 1 "$STRESS_CYCLES"); do
-        info "── цикл $i/$STRESS_CYCLES ──"
-
-        info "[$i] destroy..."
-        if tf_destroy; then
-            pass "9.${i}a destroy цикл $i"
-        else
-            fail "9.${i}a destroy цикл $i упал"
-            # Попробовать восстановиться
-            rid=$(next_run_id)
-            tf_apply \
-                -var "install_packages=true" \
-                -var "install_nginx=true" \
-                -var "install_docker=true" \
-                -var "install_run_id=$rid" || true
-            continue
-        fi
-
-        rid=$(next_run_id)
-        info "[$i] apply (run_id=$rid)..."
-        if tf_apply \
-            -var "install_packages=true" \
-            -var "install_nginx=true" \
-            -var "install_docker=true" \
-            -var "install_run_id=$rid"; then
-            pass "9.${i}b apply цикл $i"
-        else
-            fail "9.${i}b apply цикл $i упал"
-            continue
-        fi
-    done
-
-    phase_result "STRESS_CYCLES" "PASS"
-}
-
-# ══════════════════════════════════════════════════════════════════════════════
-# ФАЗА 10: FINAL_SANITY — финальная проверка состояния
-# ══════════════════════════════════════════════════════════════════════════════
-
-phase_10_final() {
-    phase_header 10 "FINAL_SANITY — финальная проверка"
-
-    # Убедиться что state на месте
-    local count
-    count=$(tf_state_count)
-    if [[ $count -ge 5 ]]; then
-        pass "10.1 state содержит $count ресурсов"
-    else
-        fail "10.1 state содержит $count ресурсов (ожидали ≥5)"
-        # Попробовать восстановить (через -var, БЕЗ изменения файлов)
-        local rid
-        rid=$(next_run_id)
-        info "пытаюсь восстановить baseline..."
-        tf_apply \
-            -var "install_packages=true" \
-            -var "install_nginx=true" \
-            -var "install_docker=true" \
-            -var "install_run_id=$rid" || warn "восстановление не удалось"
-    fi
-
-    # Idempotency финально: повторный apply → 0 changed.
-    # sless_job пересоздаются (add+destroy) — это нормально для job-ресурса.
-    # Проверяем только "0 changed" — VM и vApp не должны изменяться.
-    if tf_apply \
-        -var "install_packages=true" \
-        -var "install_nginx=true" \
-        -var "install_docker=true" \
-        -var "install_run_id=$RUN_ID"; then
-        if grep -q ', 0 changed,' /tmp/vm_tf_apply.log; then
-            pass "10.2 финальный apply → 0 changed (sless_job пересоздан — ожидаемо)"
-            grep -E 'Resources:' /tmp/vm_tf_apply.log | tail -1 | while read -r line; do
-                info "  $line"
-            done
-        else
-            fail "10.2 финальный apply изменил persistent ресурсы (ожидали 0 changed)"
-            grep -E 'added|changed|destroyed' /tmp/vm_tf_apply.log | tail -3 | while read -r line; do
-                info "  $line"
-            done
-        fi
-    else
-        fail "10.2 финальный apply упал"
-    fi
-
-    # VM доступна
-    local ip
-    ip=$(get_vm_ip)
-    if [[ -n "$ip" ]] && vm_alive "$ip"; then
-        pass "10.3 VM $ip доступна по SSH"
-
-        # Полная проверка пакетов
-        for pkg in jq htop unzip; do
-            if vm_check_package "$ip" "$pkg"; then
-                pass "10.4 пакет $pkg установлен"
-            else
-                fail "10.4 пакет $pkg НЕ установлен"
-            fi
-        done
-
-        if vm_check_binary "$ip" "nginx"; then
-            pass "10.5 nginx работает"
-        else
-            fail "10.5 nginx НЕ найден"
-        fi
-
-        if vm_check_binary "$ip" "docker"; then
-            pass "10.6 docker работает"
-        else
-            fail "10.6 docker НЕ найден"
-        fi
-
-        # nginx service активен (не просто бинарник, а именно демон)
-        if vm_ssh "$ip" "systemctl is-active nginx 2>/dev/null" 2>/dev/null | grep -q '^active$'; then
-            pass "10.7 nginx service активен (systemctl)"
-        else
-            fail "10.7 nginx service не активен"
-        fi
-
-        # docker daemon активен
-        if vm_ssh "$ip" "systemctl is-active docker 2>/dev/null" 2>/dev/null | grep -q '^active$'; then
-            pass "10.8 docker daemon активен (systemctl)"
-        else
-            fail "10.8 docker daemon не активен"
-        fi
-
-        # HTTP probe: nginx отвечает на localhost:80
-        local http_code
-        http_code=$(vm_ssh "$ip" "curl -sS -o /dev/null -w '%{http_code}' http://localhost 2>/dev/null" 2>/dev/null)
-        if [[ "$http_code" == "200" ]]; then
-            pass "10.9 nginx отвечает HTTP 200"
-        else
-            fail "10.9 nginx не отвечает HTTP 200 (code='$http_code')"
-        fi
-
-        # python3 доступен
-        local py_ver
-        py_ver=$(vm_ssh "$ip" "python3 --version 2>&1" 2>/dev/null)
-        if echo "$py_ver" | grep -q 'Python 3'; then
-            pass "10.10 python3 доступен ($py_ver)"
-        else
-            fail "10.10 python3 недоступен"
-        fi
-
-        # docker smoke: запустить контейнер и проверить вывод
-        if vm_ssh "$ip" "docker run --rm hello-world 2>&1 | grep -q 'Hello from Docker'" 2>/dev/null; then
-            pass "10.11 docker run hello-world → успешно"
-        else
-            fail "10.11 docker run hello-world → не прошёл"
-        fi
-
-        # disk space: убедиться что на VM есть место (>500MB free)
-        local free_mb
-        free_mb=$(vm_ssh "$ip" "df -m / 2>/dev/null | awk 'NR==2{print \$4}'" 2>/dev/null)
-        if [[ -n "$free_mb" && "$free_mb" -gt 500 ]]; then
-            pass "10.12 свободное место на / = ${free_mb}MB (>500MB)"
-        else
-            fail "10.12 мало места на / = ${free_mb}MB (ожидали >500MB)"
-        fi
-    else
-        fail "10.3 VM не доступна по SSH"
-    fi
-
-    phase_result "FINAL_SANITY" "PASS"
-}
-
-# ══════════════════════════════════════════════════════════════════════════════
-# MAIN
-# ══════════════════════════════════════════════════════════════════════════════
-
-echo -e "${BOLD}${CYAN}"
-echo "╔═══════════════════════════════════════════════════════════════╗"
-echo "║     VM STRESS TEST v2 (READ-ONLY) — examples/VM             ║"
-echo "║     $(date '+%Y-%m-%d %H:%M:%S')                                     ║"
-echo "║     Начальный run_id: $RUN_ID                                        ║"
-echo "║     Циклов stress: $STRESS_CYCLES                                       ║"
-echo "║     terraform.tfvars НЕ МОДИФИЦИРУЕТСЯ                      ║"
-echo "╚═══════════════════════════════════════════════════════════════╝"
-echo -e "${RESET}"
-
-# Проверить что мы в правильной директории
-if [[ ! -f "terraform.tfvars" ]]; then
-    echo -e "${RED}ОШИБКА: terraform.tfvars не найден. Запускайте из examples/VM/${RESET}"
-    exit 1
-fi
-
-if [[ ! -f "$VM_KEY" ]]; then
-    echo -e "${RED}ОШИБКА: $VM_KEY не найден${RESET}"
-    exit 1
-fi
-
-# ⛔ ПРОВЕРКА ЦЕЛОСТНОСТИ: terraform.tfvars НЕ ДОЛЖЕН БЫТЬ МОДИФИЦИРОВАН
-# Сохраняем md5 до запуска и проверяем после каждой фазы
-TFVARS_MD5=$(md5sum terraform.tfvars | awk '{print $1}')
-info "md5 terraform.tfvars = $TFVARS_MD5 (будет проверяться после каждой фазы)"
-
-check_tfvars_integrity() {
-    local current_md5
-    current_md5=$(md5sum terraform.tfvars | awk '{print $1}')
-    if [[ "$current_md5" != "$TFVARS_MD5" ]]; then
-        echo -e "${RED}⛔⛔⛔ КРИТИЧЕСКАЯ ОШИБКА: terraform.tfvars был изменён! ⛔⛔⛔${RESET}"
-        echo -e "${RED}Ожидали md5: $TFVARS_MD5${RESET}"
-        echo -e "${RED}Текущий md5: $current_md5${RESET}"
-        echo -e "${RED}АВАРИЙНАЯ ОСТАНОВКА ТЕСТА${RESET}"
-        exit 99
-    fi
-}
-
-# Запуск фаз с проверкой целостности после каждой
-phase_1_baseline;  check_tfvars_integrity
-phase_2_idempotent;  check_tfvars_integrity
-phase_3_partial_disable;  check_tfvars_integrity
-phase_4_partial_enable;  check_tfvars_integrity
-phase_5_reorder;  check_tfvars_integrity
-phase_6_manual_purge;  check_tfvars_integrity
-
-if [[ "$SKIP_DESTROY" == "1" ]]; then
-    skip "фазы 7-9 пропущены (SKIP_DESTROY=1)"
-    PHASE_RESULTS+=("DESTROY:SKIP" "RESURRECT:SKIP" "STRESS_CYCLES:SKIP")
-else
-    phase_7_destroy;  check_tfvars_integrity
-    phase_8_resurrect;  check_tfvars_integrity
-    phase_9_stress;  check_tfvars_integrity
-fi
-
-phase_10_final;  check_tfvars_integrity
-
-# ── ИТОГОВАЯ СВОДКА ──────────────────────────────────────────────────────────
-
-ELAPSED=$((SECONDS - START_TIME))
-ELAPSED_MIN=$((ELAPSED / 60))
-ELAPSED_SEC=$((ELAPSED % 60))
-
-echo ""
-echo -e "${BOLD}${CYAN}╔═══════════════════════════════════════════════════════════════╗${RESET}"
-echo -e "${BOLD}${CYAN}║                    ИТОГОВАЯ СВОДКА                           ║${RESET}"
-echo -e "${BOLD}${CYAN}╠═══════════════════════════════════════════════════════════════╣${RESET}"
-echo -e "${BOLD}  Время: ${ELAPSED_MIN}m ${ELAPSED_SEC}s${RESET}"
-echo -e "${BOLD}  ${GREEN}PASS: $PASS${RESET}  ${RED}FAIL: $FAIL${RESET}  ${YELLOW}SKIP: $SKIP${RESET}"
-echo -e "${BOLD}  Финальный run_id: $RUN_ID${RESET}"
-echo ""
-echo -e "${BOLD}  Фазы:${RESET}"
-for pr in "${PHASE_RESULTS[@]}"; do
-    name="${pr%%:*}"
-    result="${pr##*:}"
-    case "$result" in
-        PASS) echo -e "    ${GREEN}✓${RESET} $name" ;;
-        FAIL) echo -e "    ${RED}✗${RESET} $name" ;;
-        SKIP) echo -e "    ${YELLOW}○${RESET} $name" ;;
-    esac
-done
-echo -e "${BOLD}${CYAN}╚═══════════════════════════════════════════════════════════════╝${RESET}"
-
-# Финальная проверка целостности tfvars
-check_tfvars_integrity
-info "terraform.tfvars НЕ БЫЛ ИЗМЕНЁН (md5 совпадает)"
-
-# Exit code: 0 если все PASS, 1 если есть FAIL
-if [[ $FAIL -gt 0 ]]; then
-    echo -e "\n${RED}РЕЗУЛЬТАТ: FAIL ($FAIL ошибок)${RESET}"
-    exit 1
-else
-    echo -e "\n${GREEN}РЕЗУЛЬТАТ: ALL PASS${RESET}"
-    exit 0
-fi
@@ -3,16 +3,11 @@ module gitea-naeel.giteak8s.services.ngcloud.ru/naeel/sless
 go 1.25

 require (
-	github.com/eclipse/paho.mqtt.golang v1.5.1
-	github.com/go-logr/logr v1.2.3
-	github.com/google/uuid v1.6.0
 	github.com/gorilla/mux v1.8.1
 	github.com/lib/pq v1.11.2
 	github.com/minio/minio-go/v7 v7.0.99
 	github.com/onsi/ginkgo/v2 v2.6.0
 	github.com/onsi/gomega v1.24.1
-	github.com/rabbitmq/amqp091-go v1.10.0
-	github.com/segmentio/kafka-go v0.4.50
 	k8s.io/api v0.26.0
 	k8s.io/apimachinery v0.26.0
 	k8s.io/client-go v0.26.0
@@ -28,6 +23,7 @@ require (
 	github.com/evanphx/json-patch/v5 v5.6.0 // indirect
 	github.com/fsnotify/fsnotify v1.6.0 // indirect
 	github.com/go-ini/ini v1.67.0 // indirect
+	github.com/go-logr/logr v1.2.3 // indirect
 	github.com/go-logr/zapr v1.2.3 // indirect
 	github.com/go-openapi/jsonpointer v0.19.5 // indirect
 	github.com/go-openapi/jsonreference v0.20.0 // indirect
@@ -38,7 +34,7 @@ require (
 	github.com/google/gnostic v0.5.7-v3refs // indirect
 	github.com/google/go-cmp v0.5.9 // indirect
 	github.com/google/gofuzz v1.1.0 // indirect
-	github.com/gorilla/websocket v1.5.3 // indirect
+	github.com/google/uuid v1.6.0 // indirect
 	github.com/imdario/mergo v0.3.6 // indirect
 	github.com/josharian/intern v1.0.0 // indirect
 	github.com/json-iterator/go v1.1.12 // indirect
@@ -53,12 +49,12 @@ require (
 	github.com/modern-go/reflect2 v1.0.2 // indirect
 	github.com/munnerz/goautoneg v0.0.0-20191010083416-a7dc8b61c822 // indirect
 	github.com/philhofer/fwd v1.2.0 // indirect
-	github.com/pierrec/lz4/v4 v4.1.15 // indirect
 	github.com/pkg/errors v0.9.1 // indirect
 	github.com/prometheus/client_golang v1.14.0 // indirect
 	github.com/prometheus/client_model v0.3.0 // indirect
 	github.com/prometheus/common v0.37.0 // indirect
 	github.com/prometheus/procfs v0.8.0 // indirect
+	github.com/rabbitmq/amqp091-go v1.10.0 // indirect
 	github.com/rs/xid v1.6.0 // indirect
 	github.com/spf13/pflag v1.0.5 // indirect
 	github.com/tinylib/msgp v1.6.1 // indirect
@@ -69,7 +65,6 @@ require (
 	golang.org/x/crypto v0.46.0 // indirect
 	golang.org/x/net v0.48.0 // indirect
 	golang.org/x/oauth2 v0.0.0-20220223155221-ee480838109b // indirect
-	golang.org/x/sync v0.19.0 // indirect
 	golang.org/x/sys v0.39.0 // indirect
 	golang.org/x/term v0.38.0 // indirect
 	golang.org/x/text v0.32.0 // indirect
@@ -60,8 +60,6 @@ github.com/davecgh/go-spew v1.1.1/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSs
 github.com/docopt/docopt-go v0.0.0-20180111231733-ee0de3bc6815/go.mod h1:WwZ+bS3ebgob9U8Nd0kOddGdZWjyMGR8Wziv+TBNwSE=
 github.com/dustin/go-humanize v1.0.1 h1:GzkhY7T5VNhEkwH0PVJgjz+fX1rhBrR7pRT3mDkpeCY=
 github.com/dustin/go-humanize v1.0.1/go.mod h1:Mu1zIs6XwVuF/gI1OepvI0qD18qycQx+mFykh5fBlto=
-github.com/eclipse/paho.mqtt.golang v1.5.1 h1:/VSOv3oDLlpqR2Epjn1Q7b2bSTplJIeV2ISgCl2W7nE=
-github.com/eclipse/paho.mqtt.golang v1.5.1/go.mod h1:1/yJCneuyOoCOzKSsOTUc0AJfpsItBGWvYpBLimhArU=
 github.com/emicklei/go-restful/v3 v3.9.0 h1:XwGDlfxEnQZzuopoqxwSEllNcCOM9DhhFyhFIIGKwxE=
 github.com/emicklei/go-restful/v3 v3.9.0/go.mod h1:6n3XBCmQQb25CM2LCACGz8ukIrRry+4bhvbpWn3mrbc=
 github.com/envoyproxy/go-control-plane v0.9.0/go.mod h1:YTl/9mNaCwkRvm6d1a2C3ymFceY/DCBVvsKhRF0iEA4=
@@ -170,8 +168,6 @@ github.com/googleapis/gax-go/v2 v2.0.4/go.mod h1:0Wqv26UfaUD9n4G6kQubkQ+KchISgw+
 github.com/googleapis/gax-go/v2 v2.0.5/go.mod h1:DWXyrwAJ9X0FpwwEdw+IPEYBICEFu5mhpdKc/us6bOk=
 github.com/gorilla/mux v1.8.1 h1:TuBL49tXwgrFYWhqrNgrUNEY92u81SPhu7sTdzQEiWY=
 github.com/gorilla/mux v1.8.1/go.mod h1:AKf9I4AEqPTmMytcMc0KkNouC66V3BtZ4qD5fmWSiMQ=
-github.com/gorilla/websocket v1.5.3 h1:saDtZ6Pbx/0u+bgYQ3q96pZgCzfhKXGPqt7kZ72aNNg=
-github.com/gorilla/websocket v1.5.3/go.mod h1:YR8l580nyteQvAITg2hZ9XVh4b55+EU/adAjf1fMHhE=
 github.com/hashicorp/golang-lru v0.5.0/go.mod h1:/m3WP610KZHVQ1SGc6re/UDhFvYD7pJ4Ao+sR/qLZy8=
 github.com/hashicorp/golang-lru v0.5.1/go.mod h1:/m3WP610KZHVQ1SGc6re/UDhFvYD7pJ4Ao+sR/qLZy8=
 github.com/ianlancetaylor/demangle v0.0.0-20181102032728-5e5cf60278f6/go.mod h1:aSSvb/t6k1mPoxDqO4vJh6VOCGPwU4O0C2/Eqndh1Sc=
@@ -242,8 +238,6 @@ github.com/onsi/gomega v1.24.1 h1:KORJXNNTzJXzu4ScJWssJfJMnJ+2QJqhoQSRwNlze9E=
 github.com/onsi/gomega v1.24.1/go.mod h1:3AOiACssS3/MajrniINInwbfOOtfZvplPzuRSmvt1jM=
 github.com/philhofer/fwd v1.2.0 h1:e6DnBTl7vGY+Gz322/ASL4Gyp1FspeMvx1RNDoToZuM=
 github.com/philhofer/fwd v1.2.0/go.mod h1:RqIHx9QI14HlwKwm98g9Re5prTQ6LdeRQn+gXJFxsJM=
-github.com/pierrec/lz4/v4 v4.1.15 h1:MO0/ucJhngq7299dKLwIMtgTfbkoSPF6AoMYDd8Q4q0=
-github.com/pierrec/lz4/v4 v4.1.15/go.mod h1:gZWDp/Ze/IJXGXf23ltt2EXimqmTUXEy0GFuRQyBid4=
 github.com/pkg/errors v0.8.0/go.mod h1:bwawxfHBFNV+L2hUp1rHADufV3IMtnDRdf1r5NINEl0=
 github.com/pkg/errors v0.8.1/go.mod h1:bwawxfHBFNV+L2hUp1rHADufV3IMtnDRdf1r5NINEl0=
 github.com/pkg/errors v0.9.1 h1:FEBLx1zS214owpjy7qsBeixbURkuhQAwrK5UwLGTwt4=
@@ -281,8 +275,6 @@ github.com/rabbitmq/amqp091-go v1.10.0/go.mod h1:Hy4jKW5kQART1u+JkDTF9YYOQUHXqMu
 github.com/rogpeppe/go-internal v1.3.0/go.mod h1:M8bDsm7K2OlrFYOpmOWEs/qY81heoFRclV5y23lUDJ4=
 github.com/rs/xid v1.6.0 h1:fV591PaemRlL6JfRxGDEPl69wICngIQ3shQtzfy2gxU=
 github.com/rs/xid v1.6.0/go.mod h1:7XoLgs4eV+QndskICGsho+ADou8ySMSjJKDIan90Nz0=
-github.com/segmentio/kafka-go v0.4.50 h1:mcyC3tT5WeyWzrFbd6O374t+hmcu1NKt2Pu1L3QaXmc=
-github.com/segmentio/kafka-go v0.4.50/go.mod h1:Y1gn60kzLEEaW28YshXyk2+VCUKbJ3Qr6DrnT3i4+9E=
 github.com/sirupsen/logrus v1.2.0/go.mod h1:LxeOpSwHxABJmUn/MG1IvRgCAasNZTLOkJPxbbu5VWo=
 github.com/sirupsen/logrus v1.4.2/go.mod h1:tLMulIdttU9McNUspp0xgXVQah82FyeX6MwdIuYE2rE=
 github.com/sirupsen/logrus v1.6.0/go.mod h1:7uNnSEd1DgxDLC74fIahvMZmmYsHGZGEOFrfsX/uA88=
@@ -301,12 +293,6 @@ github.com/stretchr/testify v1.9.0 h1:HtqpIVDClZ4nwg75+f6Lvsy/wHu+3BoSGCbBAcpTsT
 github.com/stretchr/testify v1.9.0/go.mod h1:r2ic/lqez/lEtzL7wO/rwa5dbSLXVDPFyf8C91i36aY=
 github.com/tinylib/msgp v1.6.1 h1:ESRv8eL3u+DNHUoSAAQRE50Hm162zqAnBoGv9PzScPY=
 github.com/tinylib/msgp v1.6.1/go.mod h1:RSp0LW9oSxFut3KzESt5Voq4GVWyS+PSulT77roAqEA=
-github.com/xdg-go/pbkdf2 v1.0.0 h1:Su7DPu48wXMwC3bs7MCNG+z4FhcyEuz5dlvchbq0B0c=
-github.com/xdg-go/pbkdf2 v1.0.0/go.mod h1:jrpuAogTd400dnrH08LKmI/xc1MbPOebTwRqcT5RDeI=
-github.com/xdg-go/scram v1.1.2 h1:FHX5I5B4i4hKRVRBCFRxq1iQRej7WO3hhBuJf+UUySY=
-github.com/xdg-go/scram v1.1.2/go.mod h1:RT/sEzTbU5y00aCK8UOx6R7YryM0iF1N2MOmC3kKLN4=
-github.com/xdg-go/stringprep v1.0.4 h1:XLI/Ng3O1Atzq0oBs3TWm+5ZVgkq2aqdlvP9JtoZ6c8=
-github.com/xdg-go/stringprep v1.0.4/go.mod h1:mPGuuIYwz7CmR2bT9j4GbQqutWS1zV24gijq1dTyGkM=
 github.com/yuin/goldmark v1.1.25/go.mod h1:3hX8gzYuyVAZsxl0MRgGTJEmQBFcNTphYh9decYSb74=
 github.com/yuin/goldmark v1.1.27/go.mod h1:3hX8gzYuyVAZsxl0MRgGTJEmQBFcNTphYh9decYSb74=
 github.com/yuin/goldmark v1.1.32/go.mod h1:3hX8gzYuyVAZsxl0MRgGTJEmQBFcNTphYh9decYSb74=
@@ -319,8 +305,9 @@ go.opencensus.io v0.22.4/go.mod h1:yxeiOL68Rb0Xd1ddK5vPZ/oVn4vY4Ynel7k9FzqtOIw=
 go.uber.org/atomic v1.7.0 h1:ADUqmZGgLDDfbSL9ZmPxKTybcoEYHgpYfELNoN+7hsw=
 go.uber.org/atomic v1.7.0/go.mod h1:fEN4uk6kAWBTFdckzkM89CLk9XfWZrxpCo0nPH17wJc=
 go.uber.org/goleak v1.1.10/go.mod h1:8a7PlsEVH3e/a/GLqe5IIrQx6GzcnRmZEufDUTk4A7A=
+go.uber.org/goleak v1.2.0 h1:xqgm/S+aQvhWFTtR0XK3Jvg7z8kGV8P4X14IzwN3Eqk=
+go.uber.org/goleak v1.2.0/go.mod h1:XJYK+MuIchqpmGmUSAzotztawfKvYLUIgg7guXrwVUo=
 go.uber.org/goleak v1.3.0 h1:2K3zAYmnTNqV73imy9J1T3WC+gmCePx2hEGkimedGto=
-go.uber.org/goleak v1.3.0/go.mod h1:CoHD4mav9JJNrW/WLlf7HGZPjdw8EucARQHekz1X6bE=
 go.uber.org/multierr v1.6.0 h1:y6IPFStTAIT5Ytl7/XYmHvzXQ7S3g/IeZW9hyZ5thw4=
 go.uber.org/multierr v1.6.0/go.mod h1:cdWPpRnG4AhwMwsgIHip0KRBQjJy5kYEpYjJxpXp9iU=
 go.uber.org/zap v1.19.0/go.mod h1:xg/QME4nWcxGxrpdeYfq7UvYrLh66cuVKdrbD1XF/NI=
@@ -418,8 +405,6 @@ golang.org/x/sync v0.0.0-20200317015054-43a5402ce75a/go.mod h1:RxMgew5VJxzue5/jJ
 golang.org/x/sync v0.0.0-20200625203802-6e8e738ad208/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
 golang.org/x/sync v0.0.0-20201020160332-67f06af15bc9/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
 golang.org/x/sync v0.0.0-20201207232520-09787c993a3a/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
-golang.org/x/sync v0.19.0 h1:vV+1eWNmZ5geRlYjzm2adRgW2/mcpevXNg50YZtPCE4=
-golang.org/x/sync v0.19.0/go.mod h1:9KTHXmSnoGruLpwFjVSX0lNNA75CykiMECbovNTZqGI=
 golang.org/x/sys v0.0.0-20180830151530-49385e6e1522/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
 golang.org/x/sys v0.0.0-20180905080454-ebe1bf3edb33/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
 golang.org/x/sys v0.0.0-20181116152217-5ac8a444bdc5/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
@@ -1,27 +0,0 @@
-// Создано: 2026-04-06
-// admin_embed.go — встраивает HTML страницы администратора IoT в бинарник через go:embed.
-//
-// Страница /iot-admin доступна без JWT — данные не содержит.
-// Все данные загружаются через /iot-admin/stats (защищён ADMIN_STATS_TOKEN).
-// Почему go:embed: единый деплой, нет отдельных pod-ов, нет nginx drift.
-
-package api
-
-import (
-	_ "embed"
-	"net/http"
-)
-
-// iotAdminHTML — бинарное содержимое страницы администратора IoT, встроенное при сборке.
-//
-//go:embed ui/iot-admin.html
-var iotAdminHTML []byte
-
-// ServeIoTAdmin обрабатывает GET /iot-admin — отдаёт HTML страницу администратора.
-// Auth не нужен для HTML — сама страница ничего не содержит, только UI оболочка.
-func ServeIoTAdmin(w http.ResponseWriter, r *http.Request) {
-	w.Header().Set("Content-Type", "text/html; charset=utf-8")
-	w.Header().Set("Cache-Control", "no-cache, must-revalidate")
-	w.WriteHeader(http.StatusOK)
-	_, _ = w.Write(iotAdminHTML)
-}
@@ -1,32 +0,0 @@
-// Создано: 2026-04-04
-// console_embed.go — встраивает HTML-файл IoT консоли в бинарник оператора через go:embed.
-//
-// Файл ui/iot-console.html встраивается при компиляции и раздаётся по GET /console.
-// Путь /console доступен без JWT — это публичная статическая страница.
-// Авторизация в UI происходит через Bearer-токен который пользователь вводит сам.
-//
-// Почему go:embed а не отдельный nginx: нет лишних pod'ов, единый деплой, нет drift.
-// Почему /console без auth: HTML файл не содержит секретов, токен вводит пользователь.
-
-package api
-
-import (
-	_ "embed"
-	"net/http"
-)
-
-// iotConsoleHTML — бинарное содержимое IoT консоли, встроенное при сборке.
-// При изменении HTML-файла достаточно пересобрать оператор.
-//
-//go:embed ui/iot-console.html
-var iotConsoleHTML []byte
-
-// ServeIoTConsole обрабатывает GET /console — отдаёт HTML SPA без JWT-проверки.
-// Браузер кэширует HTML; API-запросы из JS защищены Bearer-токеном.
-func ServeIoTConsole(w http.ResponseWriter, r *http.Request) {
-	w.Header().Set("Content-Type", "text/html; charset=utf-8")
-	// Не кэшировать агрессивно — консоль обновляется вместе с оператором
-	w.Header().Set("Cache-Control", "no-cache, must-revalidate")
-	w.WriteHeader(http.StatusOK)
-	_, _ = w.Write(iotConsoleHTML)
-}
@@ -1,4 +1,4 @@
-// Изменено: 2026-04-05 (добавлено поле IoTPG для IoT телеметрии)
+// Изменено: 2026-03-11
 // Handler — общий контейнер зависимостей для всех REST handlers.
 // Все handlers получают доступ к k8s, S3 и Postgres через эту структуру.
 // Логирование через slog, маршрутизация через gorilla/mux.
@@ -28,7 +28,6 @@ import (
 	"k8s.io/apimachinery/pkg/runtime"
 	"sigs.k8s.io/controller-runtime/pkg/client"

-	"gitea-naeel.giteak8s.services.ngcloud.ru/naeel/sless/internal/storage/iotpg"
 	"gitea-naeel.giteak8s.services.ngcloud.ru/naeel/sless/internal/storage/postgres"
 	"gitea-naeel.giteak8s.services.ngcloud.ru/naeel/sless/internal/storage/s3"
 )
@@ -44,12 +43,7 @@ type Handler struct {
 	Scheme *runtime.Scheme
 	S3     *s3.Client
 	PG     *postgres.Store
-	// IoTPG — хранилище IoT телеметрии (per-tenant Postgres). nil если IOT_PG_DSN не задан.
-	IoTPG *iotpg.IoTPostgresStore
-	// KafkaBrokers — адреса Kafka брокеров (KAFKA_BROKERS env var).
-	// Используется страницей администратора для чтения consumer lag.
-	KafkaBrokers string
-	Log          *slog.Logger
+	Log    *slog.Logger
 }

 // writeJSON отправляет JSON-ответ с указанным статусом.
@@ -1,214 +0,0 @@
-// Создано: 2026-04-06
-// iot_admin_stats_handler.go — handler для страницы администратора IoT.
-//
-// Endpoints:
-//   GET /iot-admin/stats — JSON с агрегированной статистикой (защищён ADMIN_STATS_TOKEN)
-//
-// Источники данных:
-//   - PostgreSQL (IoTPG): counts per tenant, last 1h/24h, latest rows
-//   - Kafka: consumer lag (latest offset - committed offset для group iot-pg-consumer)
-//   - K8s: статус подов iot-mqtt-bridge и iot-kafka-consumer
-//
-// Авторизация: Bearer из env ADMIN_STATS_TOKEN.
-// Если ADMIN_STATS_TOKEN не задан — endpoint возвращает 503.
-
-package handler
-
-import (
-	"context"
-	"fmt"
-	"net/http"
-	"os"
-	"strings"
-	"time"
-
-	kafka "github.com/segmentio/kafka-go"
-	corev1 "k8s.io/api/core/v1"
-	"sigs.k8s.io/controller-runtime/pkg/client"
-)
-
-// iotAdminPodStatus — краткая информация о k8s pod для страницы администратора.
-type iotAdminPodStatus struct {
-	Name     string `json:"name"`
-	Phase    string `json:"phase"`
-	Ready    bool   `json:"ready"`
-	Restarts int32  `json:"restarts"`
-	Age      string `json:"age"`
-}
-
-// iotAdminKafkaStats — информация о Kafka топике и consumer lag.
-type iotAdminKafkaStats struct {
-	LatestOffset    int64  `json:"latest_offset"`
-	CommittedOffset int64  `json:"committed_offset"`
-	ConsumerLag     int64  `json:"consumer_lag"`
-	Error           string `json:"error,omitempty"`
-}
-
-// AdminStats обрабатывает GET /iot-admin/stats.
-// Проверяет Bearer-токен из ADMIN_STATS_TOKEN, затем собирает и возвращает статистику.
-func (h *Handler) AdminStats(w http.ResponseWriter, r *http.Request) {
-	adminToken := os.Getenv("ADMIN_STATS_TOKEN")
-	if adminToken == "" {
-		writeJSON(w, http.StatusServiceUnavailable, errResp("admin stats not configured: ADMIN_STATS_TOKEN not set"))
-		return
-	}
-
-	authHeader := r.Header.Get("Authorization")
-	if !strings.HasPrefix(authHeader, "Bearer ") || strings.TrimPrefix(authHeader, "Bearer ") != adminToken {
-		writeJSON(w, http.StatusUnauthorized, errResp("unauthorized"))
-		return
-	}
-
-	ctx, cancel := context.WithTimeout(r.Context(), 15*time.Second)
-	defer cancel()
-
-	result := map[string]any{
-		"collected_at": time.Now().UTC(),
-	}
-
-	// PostgreSQL: статистика по всем tenant
-	if h.IoTPG != nil {
-		pgStats, err := h.IoTPG.GetAdminStats(ctx)
-		if err != nil {
-			result["postgres"] = map[string]any{"reachable": false, "error": err.Error()}
-		} else {
-			result["postgres"] = pgStats
-		}
-	} else {
-		result["postgres"] = map[string]any{"reachable": false, "error": "IoTPG not configured"}
-	}
-
-	// Kafka: consumer lag для топика iot.telemetry / группы iot-pg-consumer
-	result["kafka"] = h.collectIotKafkaLag(ctx)
-
-	// K8s: статус подов bridge и consumer
-	result["pods"] = h.collectIotPodStatuses(ctx)
-
-	writeJSON(w, http.StatusOK, result)
-}
-
-// collectIotKafkaLag получает latest offset топика и committed offset consumer group,
-// вычисляет lag = latest - committed.
-// Topic: "iot.telemetry", Consumer Group: "iot-pg-consumer".
-func (h *Handler) collectIotKafkaLag(ctx context.Context) iotAdminKafkaStats {
-	if h.KafkaBrokers == "" {
-		return iotAdminKafkaStats{Error: "KAFKA_BROKERS not configured"}
-	}
-
-	brokers := strings.Split(h.KafkaBrokers, ",")
-	brokerAddr := kafka.TCP(brokers...)
-
-	kc := &kafka.Client{
-		Addr:    brokerAddr,
-		Timeout: 5 * time.Second,
-	}
-
-	const topic = "iot.telemetry"
-	const group = "iot-pg-consumer"
-
-	// Получаем latest offset (конец лога — сколько всего сообщений прошло)
-	offsetsResp, err := kc.ListOffsets(ctx, &kafka.ListOffsetsRequest{
-		Addr: brokerAddr,
-		Topics: map[string][]kafka.OffsetRequest{
-			topic: {kafka.LastOffsetOf(0)},
-		},
-	})
-	if err != nil {
-		return iotAdminKafkaStats{Error: fmt.Sprintf("list offsets: %v", err)}
-	}
-
-	var latestOffset int64
-	if partitions, ok := offsetsResp.Topics[topic]; ok && len(partitions) > 0 {
-		if partitions[0].Error == nil {
-			latestOffset = partitions[0].LastOffset
-		}
-	}
-
-	// Получаем committed offset consumer group (что consumer уже обработал)
-	fetchResp, err := kc.OffsetFetch(ctx, &kafka.OffsetFetchRequest{
-		Addr:    brokerAddr,
-		GroupID: group,
-		Topics:  map[string][]int{topic: {0}},
-	})
-	if err != nil {
-		return iotAdminKafkaStats{
-			LatestOffset: latestOffset,
-			Error:        fmt.Sprintf("offset fetch: %v", err),
-		}
-	}
-
-	var committedOffset int64
-	if partitions, ok := fetchResp.Topics[topic]; ok && len(partitions) > 0 {
-		if partitions[0].Error == nil {
-			committedOffset = partitions[0].CommittedOffset
-		}
-	}
-
-	lag := latestOffset - committedOffset
-	if lag < 0 {
-		lag = 0
-	}
-
-	return iotAdminKafkaStats{
-		LatestOffset:    latestOffset,
-		CommittedOffset: committedOffset,
-		ConsumerLag:     lag,
-	}
-}
-
-// collectIotPodStatuses собирает статус k8s pods для bridge и consumer по label app={name}.
-func (h *Handler) collectIotPodStatuses(ctx context.Context) map[string]any {
-	result := map[string]any{}
-
-	for _, appLabel := range []string{"iot-mqtt-bridge", "iot-kafka-consumer"} {
-		podList := &corev1.PodList{}
-		if err := h.K8s.List(ctx, podList,
-			client.InNamespace("sless"),
-			client.MatchingLabels{"app": appLabel},
-		); err != nil {
-			result[appLabel] = map[string]any{"error": err.Error()}
-			continue
-		}
-		if len(podList.Items) == 0 {
-			result[appLabel] = map[string]any{"status": "not found"}
-			continue
-		}
-
-		pod := podList.Items[0]
-		var restarts int32
-		for _, cs := range pod.Status.ContainerStatuses {
-			restarts += cs.RestartCount
-		}
-		ready := false
-		for _, cond := range pod.Status.Conditions {
-			if cond.Type == corev1.PodReady && cond.Status == corev1.ConditionTrue {
-				ready = true
-			}
-		}
-
-		result[appLabel] = iotAdminPodStatus{
-			Name:     pod.Name,
-			Phase:    string(pod.Status.Phase),
-			Ready:    ready,
-			Restarts: restarts,
-			Age:      iotFormatAge(pod.CreationTimestamp.Time),
-		}
-	}
-
-	return result
-}
-
-// iotFormatAge возвращает человекочитаемый возраст (s/m/h/d) pod-а.
-func iotFormatAge(created time.Time) string {
-	d := time.Since(created)
-	switch {
-	case d < time.Minute:
-		return fmt.Sprintf("%ds", int(d.Seconds()))
-	case d < time.Hour:
-		return fmt.Sprintf("%dm", int(d.Minutes()))
-	case d < 24*time.Hour:
-		return fmt.Sprintf("%dh", int(d.Hours()))
-	default:
-		return fmt.Sprintf("%dd", int(d.Hours()/24))
-	}
-}
@@ -1,454 +0,0 @@
-// Создано: 2026-04-04
-// iot_device_handler.go — HTTP handlers для IoT-устройств (CRUD) и MQTT auth.
-//
-// Endpoints:
-//   POST   /internal/mqtt/auth               → MQTTAuth (без JWT, для EMQX)
-//   POST   /v1/namespaces/{ns}/iot/devices   → CreateIoTDevice
-//   GET    /v1/namespaces/{ns}/iot/devices   → ListIoTDevices
-//   GET    /v1/namespaces/{ns}/iot/devices/{name} → GetIoTDevice (включает credentials)
-//   DELETE /v1/namespaces/{ns}/iot/devices/{name} → DeleteIoTDevice
-//   PATCH  /v1/namespaces/{ns}/iot/devices/{name} → UpdateIoTDevice
-//
-// MQTTAuth вызывается EMQX при каждом MQTT CONNECT:
-//   - всегда возвращает HTTP 200 (non-200 = EMQX игнорирует backend)
-//   - {"result": "allow"|"deny"} в теле
-//
-// GetIoTDevice — единственный endpoint возвращающий mqtt-password.
-// ListIoTDevices — без паролей (security by design).
-
-package handler
-
-import (
-	"crypto/subtle"
-	"encoding/json"
-	"net/http"
-	"strings"
-	"time"
-
-	corev1 "k8s.io/api/core/v1"
-	"k8s.io/apimachinery/pkg/api/errors"
-	metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
-	"sigs.k8s.io/controller-runtime/pkg/client"
-
-	iotv1alpha1 "gitea-naeel.giteak8s.services.ngcloud.ru/naeel/sless/iot/api/v1alpha1"
-)
-
-// ——————————————————————————————————————————
-// Типы запросов / ответов
-// ——————————————————————————————————————————
-
-// iotDeviceCreateRequest — тело POST при создании IoTDevice.
-type iotDeviceCreateRequest struct {
-	// Name — имя k8s объекта IoTDevice (должно быть уникальным в namespace)
-	Name string `json:"name"`
-	// DeviceID — идентификатор устройства, используется в MQTT username и имени Secret
-	DeviceID string `json:"device_id"`
-	// Enabled — активно ли устройство с момента создания
-	Enabled *bool `json:"enabled"`
-	// Metadata — произвольные метаданные (модель, локация и т.д.)
-	Metadata map[string]string `json:"metadata,omitempty"`
-}
-
-// iotDeviceUpdateRequest — тело PATCH при обновлении IoTDevice.
-type iotDeviceUpdateRequest struct {
-	// Enabled — включить/отключить устройство
-	Enabled *bool `json:"enabled"`
-}
-
-// iotDeviceResponse — ответ при чтении одного IoTDevice.
-// MQTTPassword заполняется только из GetIoTDevice (чтение из Secret).
-type iotDeviceResponse struct {
-	Name          string                     `json:"name"`
-	Namespace     string                     `json:"namespace"`
-	DeviceID      string                     `json:"device_id"`
-	Enabled       bool                       `json:"enabled"`
-	Phase         iotv1alpha1.IoTDevicePhase `json:"phase"`
-	MQTTUsername  string                     `json:"mqtt_username,omitempty"`
-	MQTTPassword  string                     `json:"mqtt_password,omitempty"` // только в GET /devices/{name}
-	SecretName    string                     `json:"secret_name,omitempty"`
-	TopicPrefix   string                     `json:"topic_prefix,omitempty"`
-	LastConnected string                     `json:"last_connected,omitempty"`
-	Message       string                     `json:"message,omitempty"`
-	Metadata      map[string]string          `json:"metadata,omitempty"`
-	CreatedAt     string                     `json:"created_at,omitempty"`
-}
-
-// mqttAuthRequest — тело запроса от EMQX при MQTT CONNECT.
-// EMQX 5.x посылает JSON: username, password, clientid, peerhost.
-type mqttAuthRequest struct {
-	Username string `json:"username"`
-	Password string `json:"password"`
-	ClientID string `json:"clientid"`
-	PeerHost string `json:"peerhost"`
-}
-
-// mqttAuthResponse — ответ для EMQX. Всегда HTTP 200.
-// result = "allow" | "deny"
-// ACL — список правил pub/sub, изолирует топики по устройству.
-type mqttAuthResponse struct {
-	Result string    `json:"result"`
-	ACL    []aclRule `json:"acl,omitempty"`
-}
-
-// aclRule — одно правило ACL для EMQX HTTP auth plugin.
-// permission: "allow" | "deny"
-// action: "publish" | "subscribe" | "all"
-// topic: точный топик или wildcard (#, +)
-type aclRule struct {
-	Permission string `json:"permission"`
-	Action     string `json:"action"`
-	Topic      string `json:"topic"`
-}
-
-// ——————————————————————————————————————————
-// Вспомогательные функции
-// ——————————————————————————————————————————
-
-// deviceToResponse конвертирует IoTDevice CRD в ответ API.
-// password передаётся отдельно — берётся из Secret только в GetIoTDevice.
-func deviceToResponse(d *iotv1alpha1.IoTDevice, password string) iotDeviceResponse {
-	resp := iotDeviceResponse{
-		Name:         d.Name,
-		Namespace:    d.Namespace,
-		DeviceID:     d.Spec.DeviceID,
-		Enabled:      d.Spec.Enabled,
-		Phase:        d.Status.Phase,
-		MQTTUsername: d.Status.MQTTUsername,
-		MQTTPassword: password,
-		SecretName:   d.Status.SecretName,
-		TopicPrefix:  d.Status.TopicPrefix,
-		Message:      d.Status.Message,
-		Metadata:     d.Spec.Metadata,
-	}
-	if d.Status.LastConnected != nil && !d.Status.LastConnected.IsZero() {
-		resp.LastConnected = d.Status.LastConnected.UTC().Format(time.RFC3339)
-	}
-	if !d.CreationTimestamp.IsZero() {
-		resp.CreatedAt = d.CreationTimestamp.UTC().Format("2006-01-02 15:04:05 UTC")
-	}
-	return resp
-}
-
-// ——————————————————————————————————————————
-// MQTT Auth — Этап 2
-// ——————————————————————————————————————————
-
-// MQTTAuth — POST /internal/mqtt/auth
-// Вызывается EMQX при каждом MQTT CONNECT.
-// НЕ защищён JWT middleware — доступен только из кластера (путь /internal/).
-//
-// Логика аутентификации:
-//  1. Распарсить username → namespace + deviceId
-//  2. Получить Secret iot-{deviceId} в namespace
-//  3. Constant-time сравнение пароля (защита от timing attacks)
-//  4. Проверить что IoTDevice существует и enabled=true
-//  5. Обновить status.lastConnected в IoTDevice
-func (h *Handler) MQTTAuth(w http.ResponseWriter, r *http.Request) {
-	var req mqttAuthRequest
-	if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
-		// Плохой JSON от EMQX — deny, но не 400 (EMQX игнорирует non-200)
-		writeJSON(w, http.StatusOK, mqttAuthResponse{Result: "deny"})
-		return
-	}
-
-	// Парсим username: "{namespace}_{deviceId}"
-	// Namespace содержит только [a-z0-9-], первый "_" — разделитель.
-	idx := strings.Index(req.Username, "_")
-	if idx < 0 {
-		writeJSON(w, http.StatusOK, mqttAuthResponse{Result: "deny"})
-		return
-	}
-	ns := req.Username[:idx]
-	deviceID := req.Username[idx+1:]
-	if ns == "" || deviceID == "" {
-		writeJSON(w, http.StatusOK, mqttAuthResponse{Result: "deny"})
-		return
-	}
-
-	// Читаем Secret с MQTT credentials
-	secretName := "iot-" + deviceID
-	secret := &corev1.Secret{}
-	if err := h.K8s.Get(r.Context(), client.ObjectKey{Namespace: ns, Name: secretName}, secret); err != nil {
-		// Secret не найден или ошибка k8s — deny
-		writeJSON(w, http.StatusOK, mqttAuthResponse{Result: "deny"})
-		return
-	}
-
-	// Constant-time сравнение пароля — защита от timing attacks
-	storedPassword := secret.Data["mqtt-password"]
-	if subtle.ConstantTimeCompare(storedPassword, []byte(req.Password)) != 1 {
-		writeJSON(w, http.StatusOK, mqttAuthResponse{Result: "deny"})
-		return
-	}
-
-	// Проверяем что IoTDevice активно
-	device := &iotv1alpha1.IoTDevice{}
-	if err := h.K8s.Get(r.Context(), client.ObjectKey{Namespace: ns, Name: deviceID}, device); err != nil {
-		// IoTDevice не найден (или удалён) — deny
-		writeJSON(w, http.StatusOK, mqttAuthResponse{Result: "deny"})
-		return
-	}
-	if !device.Spec.Enabled {
-		writeJSON(w, http.StatusOK, mqttAuthResponse{Result: "deny"})
-		return
-	}
-
-	// Обновляем lastConnected в статусе устройства (best-effort, ошибка не критична)
-	now := metav1.NewTime(time.Now().UTC())
-	device.Status.LastConnected = &now
-	if err := h.K8s.Status().Update(r.Context(), device); err != nil {
-		h.Log.Warn("mqtt auth: failed to update lastConnected", "device", deviceID, "err", err)
-		// Продолжаем — это некритично, устройство всё равно авторизовано
-	}
-
-	// Формируем ACL правила для этого подключения.
-	// Топик устройства: "{namespace}/telemetry/{deviceId}"
-	// Это то что строит эмулятор: topicPrefix + "telemetry/" + device_id
-	// topicPrefix = "{ns}/" → итого "{ns}/telemetry/{deviceId}"
-	deviceTopic := ns + "/telemetry/" + deviceID
-
-	var aclRules []aclRule
-
-	if req.ClientID == "sless-iot-bridge" {
-		// Bridge подписывается на "+/telemetry/+" (все тенанты) — разрешаем
-		// Bridge НЕ публикует через MQTT — только читает
-		aclRules = []aclRule{
-			{Permission: "allow", Action: "subscribe", Topic: "+/telemetry/+"},
-			{Permission: "deny", Action: "all", Topic: "#"},
-		}
-	} else {
-		// Обычное IoT устройство: только свой топик
-		aclRules = []aclRule{
-			{Permission: "allow", Action: "publish", Topic: deviceTopic},
-			{Permission: "allow", Action: "subscribe", Topic: deviceTopic},
-			{Permission: "deny", Action: "all", Topic: "#"},
-		}
-	}
-
-	writeJSON(w, http.StatusOK, mqttAuthResponse{
-		Result: "allow",
-		ACL:    aclRules,
-	})
-}
-
-// ——————————————————————————————————————————
-// IoT Device CRUD — Этап 4
-// ——————————————————————————————————————————
-
-// CreateIoTDevice — POST /v1/namespaces/{namespace}/iot/devices
-// Создаёт IoTDevice CRD. Контроллер асинхронно сгенерирует MQTT credentials.
-// credentials доступны через GET /devices/{name} после reconcile (phase=Active).
-func (h *Handler) CreateIoTDevice(w http.ResponseWriter, r *http.Request) {
-	ns := namespace(r)
-	var req iotDeviceCreateRequest
-	if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
-		writeJSON(w, http.StatusBadRequest, errResp("invalid JSON: "+err.Error()))
-		return
-	}
-	if req.Name == "" {
-		writeJSON(w, http.StatusBadRequest, errResp("name is required"))
-		return
-	}
-	if req.DeviceID == "" {
-		writeJSON(w, http.StatusBadRequest, errResp("device_id is required"))
-		return
-	}
-
-	enabled := true
-	if req.Enabled != nil {
-		enabled = *req.Enabled
-	}
-
-	device := &iotv1alpha1.IoTDevice{
-		ObjectMeta: metav1.ObjectMeta{
-			Name:      req.Name,
-			Namespace: ns,
-		},
-		Spec: iotv1alpha1.IoTDeviceSpec{
-			DeviceID: req.DeviceID,
-			Enabled:  enabled,
-			Metadata: req.Metadata,
-		},
-	}
-
-	if err := h.K8s.Create(r.Context(), device); err != nil {
-		if errors.IsAlreadyExists(err) {
-			writeJSON(w, http.StatusConflict, errResp("iot device already exists"))
-			return
-		}
-		writeJSON(w, http.StatusInternalServerError, errResp(err.Error()))
-		return
-	}
-
-	writeJSON(w, http.StatusCreated, deviceToResponse(device, ""))
-}
-
-// ListIoTDevices — GET /v1/namespaces/{namespace}/iot/devices
-// Возвращает список устройств БЕЗ паролей (security by design).
-func (h *Handler) ListIoTDevices(w http.ResponseWriter, r *http.Request) {
-	ns := namespace(r)
-	list := &iotv1alpha1.IoTDeviceList{}
-	if err := h.K8s.List(r.Context(), list, client.InNamespace(ns)); err != nil {
-		writeJSON(w, http.StatusInternalServerError, errResp(err.Error()))
-		return
-	}
-	result := make([]iotDeviceResponse, 0, len(list.Items))
-	for i := range list.Items {
-		result = append(result, deviceToResponse(&list.Items[i], ""))
-	}
-	writeJSON(w, http.StatusOK, result)
-}
-
-// GetIoTDevice — GET /v1/namespaces/{namespace}/iot/devices/{name}
-// Возвращает устройство включая mqtt_password из Secret.
-// mqtt_password нужен пользователю для конфигурации физического устройства.
-func (h *Handler) GetIoTDevice(w http.ResponseWriter, r *http.Request) {
-	ns := namespace(r)
-	name := pathVar(r, "name")
-
-	device := &iotv1alpha1.IoTDevice{}
-	if err := h.K8s.Get(r.Context(), client.ObjectKey{Namespace: ns, Name: name}, device); err != nil {
-		if errors.IsNotFound(err) {
-			writeJSON(w, http.StatusNotFound, errResp("iot device not found"))
-			return
-		}
-		writeJSON(w, http.StatusInternalServerError, errResp(err.Error()))
-		return
-	}
-
-	// Читаем пароль из Secret — если ещё не создан (phase=Pending), password будет пустым
-	password := ""
-	if device.Status.SecretName != "" {
-		secret := &corev1.Secret{}
-		err := h.K8s.Get(r.Context(), client.ObjectKey{Namespace: ns, Name: device.Status.SecretName}, secret)
-		if err == nil {
-			password = string(secret.Data["mqtt-password"])
-		}
-		// Если Secret не найден — просто передаём пустой пароль (устройство ещё provisioning)
-	}
-
-	writeJSON(w, http.StatusOK, deviceToResponse(device, password))
-}
-
-// DeleteIoTDevice — DELETE /v1/namespaces/{namespace}/iot/devices/{name}
-// Удаляет IoTDevice CRD. Контроллер через finalizer удалит Secret каскадно.
-func (h *Handler) DeleteIoTDevice(w http.ResponseWriter, r *http.Request) {
-	ns := namespace(r)
-	name := pathVar(r, "name")
-
-	device := &iotv1alpha1.IoTDevice{}
-	if err := h.K8s.Get(r.Context(), client.ObjectKey{Namespace: ns, Name: name}, device); err != nil {
-		if errors.IsNotFound(err) {
-			writeJSON(w, http.StatusNotFound, errResp("iot device not found"))
-			return
-		}
-		writeJSON(w, http.StatusInternalServerError, errResp(err.Error()))
-		return
-	}
-
-	if err := h.K8s.Delete(r.Context(), device); err != nil {
-		writeJSON(w, http.StatusInternalServerError, errResp(err.Error()))
-		return
-	}
-
-	w.WriteHeader(http.StatusNoContent)
-}
-
-// UpdateIoTDevice — PATCH /v1/namespaces/{namespace}/iot/devices/{name}
-// Позволяет включить/отключить устройство (spec.enabled).
-// Контроллер увидит изменение и обновит status.phase.
-func (h *Handler) UpdateIoTDevice(w http.ResponseWriter, r *http.Request) {
-	ns := namespace(r)
-	name := pathVar(r, "name")
-
-	var req iotDeviceUpdateRequest
-	if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
-		writeJSON(w, http.StatusBadRequest, errResp("invalid JSON: "+err.Error()))
-		return
-	}
-	if req.Enabled == nil {
-		writeJSON(w, http.StatusBadRequest, errResp("enabled field is required"))
-		return
-	}
-
-	device := &iotv1alpha1.IoTDevice{}
-	if err := h.K8s.Get(r.Context(), client.ObjectKey{Namespace: ns, Name: name}, device); err != nil {
-		if errors.IsNotFound(err) {
-			writeJSON(w, http.StatusNotFound, errResp("iot device not found"))
-			return
-		}
-		writeJSON(w, http.StatusInternalServerError, errResp(err.Error()))
-		return
-	}
-
-	device.Spec.Enabled = *req.Enabled
-	if err := h.K8s.Update(r.Context(), device); err != nil {
-		writeJSON(w, http.StatusInternalServerError, errResp(err.Error()))
-		return
-	}
-
-	writeJSON(w, http.StatusOK, deviceToResponse(device, ""))
-}
-
-// ——————————————————————————————————————————
-// MQTT ACL — авторизация pub/sub
-// ——————————————————————————————————————————
-
-// mqttAclRequest — тело запроса от EMQX при каждом publish/subscribe.
-type mqttAclRequest struct {
-	Username string `json:"username"`
-	ClientID string `json:"clientid"`
-	Action   string `json:"action"` // "publish" | "subscribe"
-	Topic    string `json:"topic"`
-}
-
-// MQTTAcl — POST /internal/mqtt/acl
-// Вызывается EMQX для каждого pub/sub действия.
-// НЕ защищён JWT — доступен только из кластера.
-//
-// Логика разрешений:
-//  1. Bridge clientid "sless-iot-bridge" — subscribe на любой топик (нужен для "+/telemetry/+")
-//  2. IoT Device (username "{ns}_{deviceId}") — publish/subscribe на "{ns}/telemetry/{deviceId}"
-func (h *Handler) MQTTAcl(w http.ResponseWriter, r *http.Request) {
-	var req mqttAclRequest
-	if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
-		writeJSON(w, http.StatusOK, mqttAuthResponse{Result: "deny"})
-		return
-	}
-
-	// Специальный случай: mqtt-bridge подписывается на "+/telemetry/+" (все тенанты).
-	// Публикация bridge НЕ разрешена — только чтение.
-	if req.ClientID == "sless-iot-bridge" {
-		if req.Action == "subscribe" {
-			writeJSON(w, http.StatusOK, mqttAuthResponse{Result: "allow"})
-		} else {
-			writeJSON(w, http.StatusOK, mqttAuthResponse{Result: "deny"})
-		}
-		return
-	}
-
-	// Парсим username → namespace + deviceId (формат: "{ns}_{deviceId}")
-	// strings.Index находит ПЕРВЫЙ '_' — namespace содержит только дефисы
-	idx := strings.Index(req.Username, "_")
-	if idx < 0 {
-		writeJSON(w, http.StatusOK, mqttAuthResponse{Result: "deny"})
-		return
-	}
-	ns := req.Username[:idx]
-	deviceID := req.Username[idx+1:]
-	if ns == "" || deviceID == "" {
-		writeJSON(w, http.StatusOK, mqttAuthResponse{Result: "deny"})
-		return
-	}
-
-	// Разрешённый топик: "{ns}/telemetry/{deviceId}"
-	// Это то что эмулятор строит как: topicPrefix + "telemetry/" + device_id
-	// topicPrefix = "{ns}/" → итого "{ns}/telemetry/{deviceId}"
-	allowedTopic := ns + "/telemetry/" + deviceID
-	if req.Topic == allowedTopic {
-		writeJSON(w, http.StatusOK, mqttAuthResponse{Result: "allow"})
-		return
-	}
-
-	writeJSON(w, http.StatusOK, mqttAuthResponse{Result: "deny"})
-}
@@ -1,55 +0,0 @@
-// Создано: 2026-04-05
-// iot_telemetry_handler.go — REST handler для чтения IoT телеметрии.
-//
-// Endpoint:
-//   GET /v1/namespaces/{namespace}/iot/telemetry?device={id}&limit={n}
-//
-// Авторизация: Bearer JWT → namespace validation (как все /v1/ маршруты).
-// Данные берутся из per-tenant Postgres DB через IoTPostgresStore.
-// Если IoTPG не инициализирован (IOT_PG_DSN не задан) — возвращает 503.
-
-package handler
-
-import (
-	"net/http"
-	"strconv"
-
-	"github.com/gorilla/mux"
-
-	"gitea-naeel.giteak8s.services.ngcloud.ru/naeel/sless/internal/storage/iotpg"
-)
-
-// ListIoTTelemetry обрабатывает GET /v1/namespaces/{namespace}/iot/telemetry.
-// Параметры: device (опционально), limit (default 50, max 1000).
-func (h *Handler) ListIoTTelemetry(w http.ResponseWriter, r *http.Request) {
-	if h.IoTPG == nil {
-		writeJSON(w, http.StatusServiceUnavailable, errResp("IoT telemetry storage not configured"))
-		return
-	}
-
-	ns := mux.Vars(r)["namespace"]
-	deviceID := r.URL.Query().Get("device")
-	limit := 50
-	if ls := r.URL.Query().Get("limit"); ls != "" {
-		if n, err := strconv.Atoi(ls); err == nil && n > 0 {
-			limit = n
-		}
-	}
-
-	rows, err := h.IoTPG.QueryTelemetry(r.Context(), ns, deviceID, limit)
-	if err != nil {
-		h.Log.Error("query IoT telemetry", "namespace", ns, "device", deviceID, "err", err)
-		writeJSON(w, http.StatusInternalServerError, errResp("failed to query telemetry"))
-		return
-	}
-
-	// Возвращаем пустой массив вместо null — удобнее для JS
-	if rows == nil {
-		rows = []iotpg.TelemetryRow{}
-	}
-
-	writeJSON(w, http.StatusOK, map[string]any{
-		"items": rows,
-		"count": len(rows),
-	})
-}
@@ -1,4 +1,4 @@
-// Изменено: 2026-04-05
+// Изменено: 2026-03-11
 // Auth middleware — проверяет Bearer JWT-токен из заголовка Authorization.
 //
 // Архитектура аутентификации:
@@ -10,17 +10,6 @@
 //     внешний доступ — через Ingress, где токен уже проверен на уровне API-шлюза.
 //
 // TODO v2: получать публичный ключ из nubes JWKS endpoint и проверять подпись RS256.
-//
-// ──────────────────────────────────────────────────────────────────────────────
-// ТЕСТОВЫЙ РЕЖИМ (authTestMode = true):
-//   Принимается ЛЮБАЯ строка без пробелов — не обязательно JWT.
-//   Это позволяет тестировать UI/API без реального токена nubes.
-//   Строка используется как идентификатор пользователя (аналог JWT.sub),
-//   namespace выводится из неё так же: SHA256 → первые 16 байт hex → "sless-{hex}".
-//
-//   ⚠️  ПЕРЕД ВЫХОДОМ В ПРОД: установить authTestMode = false.
-//   Для возврата к строгой JWT-валидации: одна строка ниже.
-// ──────────────────────────────────────────────────────────────────────────────

 package middleware

@@ -33,25 +22,11 @@ import (
 	"time"
 )

-// authTestMode — ТЕСТОВЫЙ РЕЖИМ аутентификации.
-//
-// true  → принимается любая строка без пробелов (не обязательно JWT).
-//
-//	Используется при разработке UI когда реальный токен nubes не нужен.
-//
-// false → строгая проверка JWT (структура + sub + exp).
-//
-//	Необходимо установить перед деплоем в прод.
-//
-// Чтобы вернуться к JWT: изменить на false.
-const authTestMode = true
-
 // Auth возвращает middleware которое требует заголовок:
 //
-//	Authorization: Bearer <token>
+//	Authorization: Bearer <jwt>
 //
-// В тестовом режиме (authTestMode=true): принимает любую строку без пробелов.
-// В боевом режиме (authTestMode=false): требует валидный JWT (sub + exp).
+// Проверяет: структура JWT (3 части), наличие "sub", отсутствие истечения "exp".
 func Auth(log *slog.Logger, next http.Handler) http.Handler {
 	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
 		header := r.Header.Get("Authorization")
@@ -66,20 +41,7 @@ func Auth(log *slog.Logger, next http.Handler) http.Handler {
 			http.Error(w, `{"error":"invalid authorization format, use Bearer <token>"}`, http.StatusUnauthorized)
 			return
 		}
-		token := parts[1]
-
-		// ── ТЕСТОВЫЙ РЕЖИМ ───────────────────────────────────────────────────
-		// Если authTestMode=true и токен — просто строка без пробелов (не JWT),
-		// пропускаем JWT-валидацию. Строка обрабатывается как произвольный sub.
-		// Чтобы вернуть строгую проверку: установить authTestMode = false.
-		if authTestMode && isPlainToken(token) {
-			log.Info("auth: test mode — plain token accepted", "remote", r.RemoteAddr, "path", r.URL.Path)
-			next.ServeHTTP(w, r)
-			return
-		}
-		// ── БОЕВОЙ РЕЖИМ / JWT ───────────────────────────────────────────────
-
-		if err := validateJWT(token); err != nil {
+		if err := validateJWT(parts[1]); err != nil {
 			log.Warn("auth: invalid token", "remote", r.RemoteAddr, "path", r.URL.Path, "reason", err.Error())
 			http.Error(w, `{"error":"invalid token"}`, http.StatusForbidden)
 			return
@@ -88,18 +50,6 @@ func Auth(log *slog.Logger, next http.Handler) http.Handler {
 	})
 }

-// isPlainToken возвращает true если токен — непустая строка без пробелов и НЕ является JWT.
-// JWT определяется по наличию ровно двух точек (xxx.yyy.zzz).
-// Логика: если строка выглядит как JWT — проверять через validateJWT (даже в testMode).
-func isPlainToken(token string) bool {
-	if token == "" || strings.ContainsAny(token, " \t\n\r") {
-		return false
-	}
-	// Если три части через точку — скорее всего JWT, проверять нормально
-	parts := strings.Split(token, ".")
-	return len(parts) != 3
-}
-
 // validateJWT проверяет структуру JWT и claim "sub" и "exp".
 // Подпись НЕ проверяется — см. комментарий к файлу.
 func validateJWT(token string) error {
@@ -1,8 +1,7 @@
-// Изменено: 2026-04-05 (добавлен route GET /iot/telemetry)
+// Изменено: 2026-03-20 (function-service-split: добавлены /services маршруты)
 // router.go — регистрация всех REST-маршрутов через gorilla/mux.
-// Все маршруты /v1/ защищены Bearer-токеном (middleware.Auth).
-// /console — публичный маршрут (статический HTML без auth).
-// CORS включён для https://iot.kube5s.ru — там хостится IoT Консоль (UI).
+// Все маршруты защищены Bearer-токеном (middleware.Auth).
+// Маршруты сгруппированы по /v1/namespaces/{namespace}/...

 package api

@@ -16,39 +15,12 @@ import (
 	"gitea-naeel.giteak8s.services.ngcloud.ru/naeel/sless/internal/api/middleware"
 )

-// corsMiddleware добавляет CORS-заголовки для IoT Консоли на https://iot.kube5s.ru.
-// Нужен потому что: консоль на https://iot.kube5s.ru, API на https://sless.kube5s.ru — разные origin.
-// Обрабатывает preflight OPTIONS запросы от браузера.
-func corsMiddleware(next http.Handler) http.Handler {
-	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
-		w.Header().Set("Access-Control-Allow-Origin", "https://iot.kube5s.ru")
-		w.Header().Set("Access-Control-Allow-Methods", "GET, POST, PUT, PATCH, DELETE, OPTIONS")
-		w.Header().Set("Access-Control-Allow-Headers", "Authorization, Content-Type")
-		w.Header().Set("Access-Control-Max-Age", "600")
-		// Preflight OPTIONS возвращаем немедленно без передачи дальше
-		if r.Method == http.MethodOptions {
-			w.WriteHeader(http.StatusNoContent)
-			return
-		}
-		next.ServeHTTP(w, r)
-	})
-}
-
 // NewRouter собирает gorilla/mux роутер со всеми маршрутами.
 // /fn/{namespace}/{name} — публичный прокси для вызова функций, без auth.
-// /console — IoT Консоль (HTML SPA), без auth, с CORS.
-// /v1/ — защищён JWT-аутентификацией (middleware.Auth), с CORS.
+// /v1/ — защищён JWT-аутентификацией (middleware.Auth).
 func NewRouter(h *handler.Handler, log *slog.Logger) http.Handler {
 	r := mux.NewRouter()

-	// IoT Консоль — статический HTML, публично доступен
-	r.HandleFunc("/console", ServeIoTConsole).Methods(http.MethodGet)
-
-	// IoT Admin — страница администратора (HTML без auth + JSON API с ADMIN_STATS_TOKEN)
-	// Не для конечных пользователей: показывает Kafka lag, pod statuses, PG stats per tenant.
-	r.HandleFunc("/iot-admin", ServeIoTAdmin).Methods(http.MethodGet)
-	r.HandleFunc("/iot-admin/stats", h.AdminStats).Methods(http.MethodGet)
-
 	// Публичный прокси для вызова HTTP-триггеров — без auth токена
 	// Все HTTP методы разрешены (GET/POST/PUT/... — решает сама функция)
 	r.PathPrefix("/fn/{namespace}/{name}").HandlerFunc(h.InvokeFunction)
@@ -98,28 +70,12 @@ func NewRouter(h *handler.Handler, log *slog.Logger) http.Handler {
 	v1.HandleFunc("/namespaces/{namespace}/jobs/{name}", h.DeleteJob).Methods(http.MethodDelete)
 	v1.HandleFunc("/namespaces/{namespace}/jobs/{name}/upload", h.UploadJobCode).Methods(http.MethodPost)

-	// IoT Devices CRUD — защищены JWT (как все /v1/ маршруты)
-	v1.HandleFunc("/namespaces/{namespace}/iot/devices", h.ListIoTDevices).Methods(http.MethodGet)
-	v1.HandleFunc("/namespaces/{namespace}/iot/devices", h.CreateIoTDevice).Methods(http.MethodPost)
-	v1.HandleFunc("/namespaces/{namespace}/iot/devices/{name}", h.GetIoTDevice).Methods(http.MethodGet)
-	v1.HandleFunc("/namespaces/{namespace}/iot/devices/{name}", h.DeleteIoTDevice).Methods(http.MethodDelete)
-	v1.HandleFunc("/namespaces/{namespace}/iot/devices/{name}", h.UpdateIoTDevice).Methods(http.MethodPatch)
-
-	// IoT Telemetry — чтение сырых данных от устройств (Postgres per-tenant)
-	v1.HandleFunc("/namespaces/{namespace}/iot/telemetry", h.ListIoTTelemetry).Methods(http.MethodGet)
-
-	// MQTT Auth — БЕЗ JWT. Вызывается EMQX при MQTT CONNECT из кластера.
-	// /internal/ недоступен снаружи (Ingress не проксирует /internal/).
-	r.HandleFunc("/internal/mqtt/auth", h.MQTTAuth).Methods(http.MethodPost)
-	// MQTT ACL — БЕЗ JWT. Вызывается EMQX при каждом pub/sub для проверки прав.
-	// Изолирует клиента в пределах его топиков: {namespace}/{deviceId}/#
-	r.HandleFunc("/internal/mqtt/acl", h.MQTTAcl).Methods(http.MethodPost)
-
-	// Цепочка middleware: CORS → logging → (auth только для /v1/) → router
-	// /fn/ — без auth, /console — без auth, /v1/ — с auth.
+	// Цепочка middleware: logging → (auth только для /v1/) → router
+	// /fn/ — без auth, /v1/ — с auth.
+	// Используем gorilla/mux Use() чтобы auth применялся только к v1 суброутеру.
 	v1.Use(func(next http.Handler) http.Handler {
 		return middleware.Auth(log, next)
 	})

-	return corsMiddleware(middleware.Logging(log, r))
+	return middleware.Logging(log, r)
 }
@@ -1,547 +0,0 @@
-<!DOCTYPE html>
-<!-- Создано: 2026-04-06
-     iot-admin.html — страница администратора IoT pipeline.
-     Показывает: PostgreSQL stats per tenant, Kafka consumer lag, K8s pod statuses.
-     Auth: ADMIN_STATS_TOKEN вводится вручную и хранится в sessionStorage.
-     Раздаётся по GET /iot-admin (go:embed в бинарнике оператора).
-     НЕ для конечных пользователей — только для администратора платформы. -->
-<html lang="ru">
-<head>
-  <meta charset="UTF-8">
-  <meta name="viewport" content="width=device-width, initial-scale=1.0">
-  <title>Nubes IoT Admin</title>
-  <link rel="icon" href="https://terra.k8c.ru/docs/nubes/nubes/2.0.2/30_registry/assets/favicon.png">
-  <style>
-    /* Nubes brand palette — те же цвета что в iot-console.html */
-    *, *::before, *::after { box-sizing: border-box; margin: 0; padding: 0; }
-    body {
-      font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', system-ui, sans-serif;
-      background: #001120; color: #e2ecf6; min-height: 100vh;
-    }
-
-    /* Navbar */
-    .navbar {
-      background: #001C34; border-bottom: 1px solid #0b2d50;
-      padding: 0 28px; height: 58px;
-      display: flex; align-items: center; gap: 14px;
-    }
-    .navbar-logo { display: flex; align-items: center; gap: 10px; text-decoration: none; }
-    .navbar-logo img { height: 18px; filter: brightness(0) invert(1); }
-    .navbar-logo-sep { width: 1px; height: 18px; background: #1a4a73; margin: 0 4px; }
-    .navbar-title { font-size: 15px; font-weight: 600; color: #e2ecf6; }
-    .navbar-badge {
-      background: #2d1a00; border: 1px solid #7a3a00; color: #f0a030;
-      font-size: 10px; font-weight: 700; padding: 2px 7px; border-radius: 4px;
-      letter-spacing: 0.5px; text-transform: uppercase;
-    }
-    .navbar-spacer { flex: 1; }
-    .navbar-refresh {
-      background: #0f3a60; border: 1px solid #1a5a8a; color: #7fc8f8;
-      padding: 6px 14px; border-radius: 6px; font-size: 13px; cursor: pointer;
-      transition: background 0.15s;
-    }
-    .navbar-refresh:hover { background: #1a5080; }
-    .navbar-refresh:disabled { opacity: 0.4; cursor: not-allowed; }
-
-    /* Layout */
-    .container { max-width: 1280px; margin: 0 auto; padding: 28px 24px; }
-
-    /* Auth box */
-    .auth-box {
-      background: #001929; border: 1px solid #0b2d50; border-radius: 12px;
-      padding: 40px; max-width: 480px; margin: 80px auto;
-      display: flex; flex-direction: column; gap: 16px;
-    }
-    .auth-box h2 { font-size: 20px; font-weight: 600; color: #7fc8f8; }
-    .auth-box p { font-size: 13px; color: #6b8eaa; }
-    .auth-input {
-      background: #001120; border: 1px solid #1a4a73; color: #e2ecf6;
-      padding: 10px 14px; border-radius: 8px; font-size: 14px; font-family: monospace;
-      width: 100%; outline: none;
-    }
-    .auth-input:focus { border-color: #1a7fd4; }
-    .auth-btn {
-      background: #1a7fd4; border: none; color: #fff;
-      padding: 10px 20px; border-radius: 8px; font-size: 14px; cursor: pointer;
-      font-weight: 600; transition: background 0.15s;
-    }
-    .auth-btn:hover { background: #1a6ab8; }
-    .auth-error { color: #f87171; font-size: 13px; }
-
-    /* Section header */
-    .section-header {
-      display: flex; align-items: center; gap: 10px;
-      margin-bottom: 16px; padding-bottom: 10px;
-      border-bottom: 1px solid #0b2d50;
-    }
-    .section-icon { width: 20px; height: 20px; opacity: 0.7; }
-    .section-title { font-size: 16px; font-weight: 600; color: #a0c4e8; }
-    .section { margin-bottom: 32px; }
-
-    /* Cards grid */
-    .cards { display: grid; grid-template-columns: repeat(auto-fill, minmax(280px, 1fr)); gap: 16px; }
-
-    /* Stat card */
-    .card {
-      background: #001929; border: 1px solid #0b2d50; border-radius: 10px;
-      padding: 20px;
-    }
-    .card-title { font-size: 12px; color: #6b8eaa; text-transform: uppercase; letter-spacing: 0.5px; margin-bottom: 8px; }
-    .card-value { font-size: 28px; font-weight: 700; color: #e2ecf6; }
-    .card-sub { font-size: 12px; color: #6b8eaa; margin-top: 4px; }
-    .card-accent { color: #1a7fd4; }
-    .card-warn { color: #f59e0b; }
-    .card-ok { color: #34d399; }
-    .card-err { color: #f87171; }
-
-    /* Pod status card */
-    .pod-card {
-      background: #001929; border: 1px solid #0b2d50; border-radius: 10px;
-      padding: 20px; display: flex; flex-direction: column; gap: 8px;
-    }
-    .pod-name { font-size: 13px; font-weight: 600; color: #7fc8f8; font-family: monospace; }
-    .pod-row { display: flex; justify-content: space-between; font-size: 12px; }
-    .pod-label { color: #6b8eaa; }
-    .pod-val { color: #e2ecf6; }
-    .badge {
-      display: inline-block; padding: 2px 8px; border-radius: 4px;
-      font-size: 11px; font-weight: 700;
-    }
-    .badge-ok { background: #052e16; color: #34d399; border: 1px solid #064e3b; }
-    .badge-warn { background: #2d1c00; color: #f59e0b; border: 1px solid #4d3000; }
-    .badge-err { background: #300; color: #f87171; border: 1px solid #500; }
-
-    /* Tenant table */
-    .tenant-table { width: 100%; border-collapse: collapse; font-size: 13px; }
-    .tenant-table th {
-      text-align: left; padding: 8px 12px; color: #6b8eaa;
-      border-bottom: 1px solid #0b2d50; font-weight: 600; font-size: 11px;
-      text-transform: uppercase; letter-spacing: 0.3px;
-    }
-    .tenant-table td { padding: 10px 12px; border-bottom: 1px solid #071a28; vertical-align: top; }
-    .tenant-table tr:last-child td { border-bottom: none; }
-    .tenant-table tr:hover td { background: rgba(26,127,212,0.05); }
-    .ns-tag {
-      font-family: monospace; font-size: 12px; color: #7fc8f8;
-      background: #0b2d50; padding: 2px 6px; border-radius: 4px;
-    }
-    .num-big { font-size: 16px; font-weight: 600; color: #e2ecf6; }
-    .num-small { font-size: 12px; color: #6b8eaa; }
-
-    /* Latest msgs mini list */
-    .latest-list { display: flex; flex-direction: column; gap: 4px; }
-    .latest-item {
-      background: #001120; border: 1px solid #0b2d50; border-radius: 6px;
-      padding: 6px 10px; font-size: 11px;
-    }
-    .latest-dev { color: #7fc8f8; font-weight: 600; }
-    .latest-ts { color: #6b8eaa; margin-left: 6px; }
-    .latest-payload { color: #a0c4e8; margin-top: 2px; word-break: break-all; font-family: monospace; }
-
-    /* Last updated */
-    .last-updated { font-size: 12px; color: #2d5070; text-align: center; margin-top: 16px; }
-
-    /* Status dot */
-    .dot { display: inline-block; width: 8px; height: 8px; border-radius: 50%; margin-right: 6px; }
-    .dot-ok { background: #34d399; }
-    .dot-warn { background: #f59e0b; }
-    .dot-err { background: #f87171; }
-
-    /* Kafka lag bar */
-    .lag-bar-wrap { background: #001120; border-radius: 4px; height: 6px; margin-top: 8px; overflow: hidden; }
-    .lag-bar { height: 100%; border-radius: 4px; transition: width 0.5s; min-width: 2px; }
-    .lag-bar-ok { background: #34d399; }
-    .lag-bar-warn { background: #f59e0b; }
-
-    /* Spinner */
-    .spinner {
-      border: 3px solid #0b2d50; border-top-color: #1a7fd4;
-      border-radius: 50%; width: 32px; height: 32px;
-      animation: spin 0.8s linear infinite;
-      margin: 60px auto;
-    }
-    @keyframes spin { to { transform: rotate(360deg); } }
-
-    /* Error banner */
-    .error-banner {
-      background: #1a0000; border: 1px solid #5a0000; color: #f87171;
-      padding: 12px 16px; border-radius: 8px; font-size: 13px; margin-bottom: 20px;
-    }
-
-    /* Auto-refresh indicator */
-    .refresh-timer {
-      font-size: 11px; color: #2d5070; display: flex; align-items: center; gap: 6px;
-    }
-    .refresh-progress {
-      width: 60px; height: 2px; background: #0b2d50; border-radius: 2px; overflow: hidden;
-    }
-    .refresh-bar {
-      height: 100%; background: #1a7fd4; border-radius: 2px;
-      transition: width 1s linear;
-    }
-  </style>
-</head>
-<body>
-
-<!-- Navbar -->
-<nav class="navbar">
-  <a class="navbar-logo" href="#" aria-label="Nubes">
-    <img src="https://terra.k8c.ru/docs/nubes/nubes/2.0.2/30_registry/assets/logo.svg" alt="Nubes">
-  </a>
-  <div class="navbar-logo-sep"></div>
-  <span class="navbar-title">IoT Admin</span>
-  <span class="navbar-badge">Admin Only</span>
-  <div class="navbar-spacer"></div>
-  <div class="refresh-timer" id="refreshTimer" style="display:none">
-    <span id="refreshCountdown">30</span>s
-    <div class="refresh-progress"><div class="refresh-bar" id="refreshBar" style="width:100%"></div></div>
-  </div>
-  <button class="navbar-refresh" id="btnRefresh" onclick="loadStats()" disabled>Обновить</button>
-</nav>
-
-<!-- Main content -->
-<div class="container">
-  <!-- Auth box (показывается до ввода токена) -->
-  <div class="auth-box" id="authBox">
-    <h2>Доступ для администратора</h2>
-    <p>Введите ADMIN_STATS_TOKEN для просмотра статистики IoT pipeline.</p>
-    <input class="auth-input" id="tokenInput" type="password"
-           placeholder="Bearer token..." autocomplete="off"
-           onkeydown="if(event.key==='Enter') doAuth()">
-    <button class="auth-btn" onclick="doAuth()">Войти</button>
-    <div class="auth-error" id="authError" style="display:none"></div>
-  </div>
-
-  <!-- Контент (показывается после авторизации) -->
-  <div id="mainContent" style="display:none">
-    <div class="error-banner" id="errorBanner" style="display:none"></div>
-
-    <!-- Spinner при загрузке -->
-    <div class="spinner" id="spinner"></div>
-
-    <!-- Данные -->
-    <div id="dataContent" style="display:none">
-
-      <!-- Kafka -->
-      <div class="section">
-        <div class="section-header">
-          <svg class="section-icon" viewBox="0 0 24 24" fill="none" stroke="#7fc8f8" stroke-width="2">
-            <path d="M12 2L2 7l10 5 10-5-10-5z"/><path d="M2 17l10 5 10-5"/><path d="M2 12l10 5 10-5"/>
-          </svg>
-          <span class="section-title">Kafka</span>
-        </div>
-        <div class="cards" id="kafkaCards"></div>
-      </div>
-
-      <!-- K8s Pods -->
-      <div class="section">
-        <div class="section-header">
-          <svg class="section-icon" viewBox="0 0 24 24" fill="none" stroke="#7fc8f8" stroke-width="2">
-            <rect x="2" y="3" width="20" height="14" rx="2"/><path d="M8 21h8M12 17v4"/>
-          </svg>
-          <span class="section-title">Pods</span>
-        </div>
-        <div class="cards" id="podCards"></div>
-      </div>
-
-      <!-- PostgreSQL per tenant -->
-      <div class="section">
-        <div class="section-header">
-          <svg class="section-icon" viewBox="0 0 24 24" fill="none" stroke="#7fc8f8" stroke-width="2">
-            <ellipse cx="12" cy="5" rx="9" ry="3"/><path d="M3 5v14c0 1.66 4.03 3 9 3s9-1.34 9-3V5"/>
-            <path d="M3 12c0 1.66 4.03 3 9 3s9-1.34 9-3"/>
-          </svg>
-          <span class="section-title">PostgreSQL — Telemetry</span>
-        </div>
-        <div class="cards" style="margin-bottom:16px" id="pgSummaryCards"></div>
-        <div style="background:#001929;border:1px solid #0b2d50;border-radius:10px;overflow:auto">
-          <table class="tenant-table" id="tenantTable">
-            <thead>
-              <tr>
-                <th>Namespace</th>
-                <th>Total</th>
-                <th>Last 1h</th>
-                <th>Last 24h</th>
-                <th>Последние сообщения</th>
-              </tr>
-            </thead>
-            <tbody id="tenantTableBody"></tbody>
-          </table>
-        </div>
-      </div>
-
-      <div class="last-updated" id="lastUpdated"></div>
-    </div>
-  </div>
-</div>
-
-<script>
-// ── State ──────────────────────────────────────────────────────────────────
-const API_BASE = window.location.origin;
-let adminToken = sessionStorage.getItem('iot_admin_token') || '';
-let refreshInterval = null;
-let refreshCountdown = 30;
-
-// ── Auth ───────────────────────────────────────────────────────────────────
-function doAuth() {
-  const input = document.getElementById('tokenInput').value.trim();
-  if (!input) return;
-  adminToken = input;
-  sessionStorage.setItem('iot_admin_token', adminToken);
-  document.getElementById('authBox').style.display = 'none';
-  document.getElementById('mainContent').style.display = 'block';
-  loadStats();
-}
-
-function showAuthError(msg) {
-  const el = document.getElementById('authError');
-  el.textContent = msg;
-  el.style.display = 'block';
-  // Сбрасываем токен — он не подошёл
-  adminToken = '';
-  sessionStorage.removeItem('iot_admin_token');
-  document.getElementById('authBox').style.display = 'block';
-  document.getElementById('mainContent').style.display = 'none';
-  if (refreshInterval) { clearInterval(refreshInterval); refreshInterval = null; }
-  document.getElementById('refreshTimer').style.display = 'none';
-}
-
-// Если токен уже в sessionStorage — пропускаем auth box
-if (adminToken) {
-  document.getElementById('authBox').style.display = 'none';
-  document.getElementById('mainContent').style.display = 'block';
-  document.getElementById('spinner').style.display = 'block';
-}
-
-// ── Load stats ─────────────────────────────────────────────────────────────
-async function loadStats() {
-  if (!adminToken) return;
-  document.getElementById('btnRefresh').disabled = true;
-  document.getElementById('spinner').style.display = 'block';
-  document.getElementById('dataContent').style.display = 'none';
-  document.getElementById('errorBanner').style.display = 'none';
-
-  resetRefreshTimer();
-
-  try {
-    const resp = await fetch(`${API_BASE}/iot-admin/stats`, {
-      headers: { 'Authorization': `Bearer ${adminToken}` }
-    });
-
-    if (resp.status === 401 || resp.status === 503) {
-      const body = await resp.json().catch(() => ({}));
-      showAuthError(body.error || 'Ошибка авторизации');
-      document.getElementById('spinner').style.display = 'none';
-      return;
-    }
-
-    if (!resp.ok) {
-      throw new Error(`HTTP ${resp.status}`);
-    }
-
-    const data = await resp.json();
-    renderAll(data);
-    document.getElementById('spinner').style.display = 'none';
-    document.getElementById('dataContent').style.display = 'block';
-    document.getElementById('refreshTimer').style.display = 'flex';
-    document.getElementById('lastUpdated').textContent =
-      'Обновлено: ' + new Date(data.collected_at).toLocaleTimeString('ru-RU');
-    setupAutoRefresh();
-  } catch (e) {
-    document.getElementById('spinner').style.display = 'none';
-    showBanner('Ошибка загрузки данных: ' + e.message);
-    document.getElementById('dataContent').style.display = 'block';
-  } finally {
-    document.getElementById('btnRefresh').disabled = false;
-  }
-}
-
-function showBanner(msg) {
-  const el = document.getElementById('errorBanner');
-  el.textContent = msg;
-  el.style.display = 'block';
-}
-
-// ── Auto-refresh ───────────────────────────────────────────────────────────
-function setupAutoRefresh() {
-  if (refreshInterval) return; // уже запущен
-  refreshInterval = setInterval(() => {
-    refreshCountdown--;
-    document.getElementById('refreshCountdown').textContent = refreshCountdown;
-    const pct = (refreshCountdown / 30) * 100;
-    document.getElementById('refreshBar').style.width = pct + '%';
-    if (refreshCountdown <= 0) {
-      clearInterval(refreshInterval);
-      refreshInterval = null;
-      loadStats();
-    }
-  }, 1000);
-}
-
-function resetRefreshTimer() {
-  if (refreshInterval) { clearInterval(refreshInterval); refreshInterval = null; }
-  refreshCountdown = 30;
-  document.getElementById('refreshCountdown').textContent = '30';
-  document.getElementById('refreshBar').style.width = '100%';
-}
-
-// ── Render ─────────────────────────────────────────────────────────────────
-function renderAll(data) {
-  renderKafka(data.kafka || {});
-  renderPods(data.pods || {});
-  renderPostgres(data.postgres || {});
-}
-
-// Kafka section
-function renderKafka(kafka) {
-  const el = document.getElementById('kafkaCards');
-  if (kafka.error) {
-    el.innerHTML = `<div class="card"><div class="card-title">Ошибка</div>
-      <div class="card-value card-err" style="font-size:14px">${esc(kafka.error)}</div></div>`;
-    return;
-  }
-
-  const lag = kafka.consumer_lag || 0;
-  const latest = kafka.latest_offset || 0;
-  const committed = kafka.committed_offset || 0;
-  const lagClass = lag === 0 ? 'card-ok' : lag < 100 ? 'card-warn' : 'card-err';
-  const barClass = lag === 0 ? 'lag-bar-ok' : 'lag-bar-warn';
-  const barWidth = latest > 0 ? Math.max(2, Math.round((committed / latest) * 100)) : 100;
-
-  el.innerHTML = `
-    <div class="card">
-      <div class="card-title">Consumer Lag</div>
-      <div class="card-value ${lagClass}">${lag}</div>
-      <div class="card-sub">iot-pg-consumer / iot.telemetry</div>
-      <div class="lag-bar-wrap"><div class="lag-bar ${barClass}" style="width:${barWidth}%"></div></div>
-    </div>
-    <div class="card">
-      <div class="card-title">Latest Offset (всего прошло)</div>
-      <div class="card-value card-accent">${latest.toLocaleString()}</div>
-      <div class="card-sub">Kafka log end offset</div>
-    </div>
-    <div class="card">
-      <div class="card-title">Committed Offset</div>
-      <div class="card-value">${committed.toLocaleString()}</div>
-      <div class="card-sub">Consumer обработал</div>
-    </div>`;
-}
-
-// Pods section
-function renderPods(pods) {
-  const el = document.getElementById('podCards');
-  el.innerHTML = '';
-
-  const labels = {
-    'iot-mqtt-bridge': 'MQTT Bridge',
-    'iot-kafka-consumer': 'Kafka Consumer'
-  };
-
-  for (const [key, pod] of Object.entries(pods)) {
-    const title = labels[key] || key;
-    if (pod.error || pod.status === 'not found') {
-      el.innerHTML += `
-        <div class="pod-card">
-          <div class="pod-name">${esc(title)}</div>
-          <div style="color:#f87171;font-size:12px">${esc(pod.error || 'Pod not found')}</div>
-        </div>`;
-      continue;
-    }
-
-    const readyBadge = pod.ready
-      ? '<span class="badge badge-ok">Ready</span>'
-      : '<span class="badge badge-warn">Not Ready</span>';
-    const restartColor = pod.restarts > 5 ? 'card-err' : pod.restarts > 0 ? 'card-warn' : 'card-ok';
-
-    el.innerHTML += `
-      <div class="pod-card">
-        <div class="pod-name">
-          <span class="dot dot-${pod.ready ? 'ok' : 'warn'}"></span>${esc(title)}
-        </div>
-        <div class="pod-row"><span class="pod-label">Pod</span><span class="pod-val" style="font-family:monospace;font-size:11px">${esc(pod.name)}</span></div>
-        <div class="pod-row"><span class="pod-label">Phase</span><span class="pod-val">${esc(pod.phase)} ${readyBadge}</span></div>
-        <div class="pod-row"><span class="pod-label">Restarts</span><span class="pod-val ${restartColor}">${pod.restarts}</span></div>
-        <div class="pod-row"><span class="pod-label">Age</span><span class="pod-val">${esc(pod.age)}</span></div>
-      </div>`;
-  }
-}
-
-// Postgres section
-function renderPostgres(pg) {
-  const summaryEl = document.getElementById('pgSummaryCards');
-  const tbodyEl = document.getElementById('tenantTableBody');
-
-  if (!pg.reachable) {
-    summaryEl.innerHTML = `<div class="card"><div class="card-title">Ошибка</div>
-      <div class="card-value card-err" style="font-size:14px">${esc(pg.error || 'Unreachable')}</div></div>`;
-    tbodyEl.innerHTML = '';
-    return;
-  }
-
-  const tenants = pg.tenants || [];
-  const totalAll = pg.total_all || 0;
-
-  summaryEl.innerHTML = `
-    <div class="card">
-      <div class="card-title">Всего записей</div>
-      <div class="card-value card-accent">${totalAll.toLocaleString()}</div>
-      <div class="card-sub">Все tenant, iot_telemetry</div>
-    </div>
-    <div class="card">
-      <div class="card-title">Tenant-ов</div>
-      <div class="card-value">${tenants.length}</div>
-      <div class="card-sub">Активных namespace</div>
-    </div>`;
-
-  tbodyEl.innerHTML = tenants.map(t => {
-    if (t.error) {
-      return `<tr><td><span class="ns-tag">${esc(t.namespace)}</span></td>
-        <td colspan="4" style="color:#f87171">${esc(t.error)}</td></tr>`;
-    }
-    const latest = (t.latest || []).slice(0, 3);
-    const latestHtml = latest.length === 0
-      ? '<span style="color:#2d5070">нет данных</span>'
-      : `<div class="latest-list">${latest.map(row => `
-          <div class="latest-item">
-            <span class="latest-dev">${esc(row.device_id)}</span>
-            <span class="latest-ts">${formatTs(row.ts)}</span>
-            <div class="latest-payload">${esc(truncate(JSON.stringify(row.payload), 80))}</div>
-          </div>`).join('')}</div>`;
-
-    return `<tr>
-      <td><span class="ns-tag">${esc(t.namespace)}</span><br>
-          <span style="font-size:11px;color:#2d5070">${esc(t.db_name)}</span></td>
-      <td><span class="num-big">${(t.total||0).toLocaleString()}</span></td>
-      <td><span class="num-small">${(t.last_1h||0).toLocaleString()}</span></td>
-      <td><span class="num-small">${(t.last_24h||0).toLocaleString()}</span></td>
-      <td>${latestHtml}</td>
-    </tr>`;
-  }).join('');
-}
-
-// ── Utils ──────────────────────────────────────────────────────────────────
-function esc(str) {
-  if (str == null) return '';
-  return String(str).replace(/&/g,'&amp;').replace(/</g,'&lt;').replace(/>/g,'&gt;');
-}
-
-function truncate(str, len) {
-  if (!str) return '';
-  return str.length > len ? str.slice(0, len) + '…' : str;
-}
-
-function formatTs(ts) {
-  if (!ts) return '';
-  try {
-    const d = new Date(ts);
-    return d.toLocaleTimeString('ru-RU', {hour:'2-digit', minute:'2-digit', second:'2-digit'});
-  } catch { return ts; }
-}
-
-// ── Init ───────────────────────────────────────────────────────────────────
-if (adminToken) {
-  loadStats();
-}
-</script>
-</body>
-</html>
@@ -1,398 +0,0 @@
-// Создано: 2026-04-05
-// iot_telemetry_store.go — управление per-tenant PostgreSQL databases для IoT телеметрии.
-//
-// Архитектура (принято 2026-04-04, см. doc/decisions/iot-telemetry-storage-2026-04-04.md):
-//   - Один Postgres инстанс (iot-postgres.sless.svc) — отдельный от sless postgres
-//   - Отдельная DATABASE per tenant: tenant_{namespace} (дефисы → подчёркивания)
-//   - Suперюзер iot_admin управляет всеми DBs; клиенты читают только через REST API
-//   - Пароли tenant хранятся в таблице tenant_credentials в management DB iot_platform
-//
-// Почему tenant_credentials в БД, а не в k8s Secret:
-//   mqtt-bridge вызывает InsertTelemetry в горячем пути MQTT.
-//   k8s API round-trip на каждое сообщение — неприемлемо.
-//
-// Подключение к tenant DB: суперюзер iot_admin, DSN строится заменой db name в adminDSN.
-// Кэширование: sync.Map для *sql.DB per tenant (lazy init при первом обращении).
-
-package iotpg
-
-import (
-	"context"
-	"database/sql"
-	"encoding/json"
-	"errors"
-	"fmt"
-	"log/slog"
-	"os"
-	"strings"
-	"sync"
-	"time"
-
-	"github.com/google/uuid"
-	"github.com/lib/pq"
-)
-
-// IoTPostgresStore управляет per-tenant Postgres databases для IoT телеметрии.
-type IoTPostgresStore struct {
-	adminDB  *sql.DB
-	adminDSN string
-	tenants  sync.Map
-	log      *slog.Logger
-}
-
-// TelemetryRow — одна запись телеметрии из таблицы iot_telemetry.
-type TelemetryRow struct {
-	ID       int64           `json:"id"`
-	DeviceID string          `json:"device_id"`
-	Ts       time.Time       `json:"ts"`
-	Payload  json.RawMessage `json:"payload"`
-}
-
-// New подключается к management DB (iot_platform) и создаёт служебные таблицы.
-func New(adminDSN string, log *slog.Logger) (*IoTPostgresStore, error) {
-	db, err := sql.Open("postgres", adminDSN)
-	if err != nil {
-		return nil, fmt.Errorf("iotpg: open admin DB: %w", err)
-	}
-	ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
-	defer cancel()
-	if err := db.PingContext(ctx); err != nil {
-		db.Close()
-		return nil, fmt.Errorf("iotpg: ping admin DB: %w", err)
-	}
-	db.SetMaxOpenConns(5)
-	db.SetMaxIdleConns(2)
-	db.SetConnMaxLifetime(5 * time.Minute)
-
-	store := &IoTPostgresStore{adminDB: db, adminDSN: adminDSN, log: log}
-	if err := store.initManagementSchema(ctx); err != nil {
-		db.Close()
-		return nil, fmt.Errorf("iotpg: init management schema: %w", err)
-	}
-	log.Info("iotpg: connected to IoT Postgres management DB")
-	return store, nil
-}
-
-// NewFromEnv создаёт store из env var IOT_PG_DSN.
-// Возвращает (nil, nil) если переменная не задана — IoT Postgres опционален.
-func NewFromEnv(log *slog.Logger) (*IoTPostgresStore, error) {
-	dsn := os.Getenv("IOT_PG_DSN")
-	if dsn == "" {
-		log.Info("iotpg: IOT_PG_DSN not set, IoT telemetry disabled")
-		return nil, nil
-	}
-	return New(dsn, log)
-}
-
-// initManagementSchema создаёт таблицу tenant_credentials в iot_platform.
-func (s *IoTPostgresStore) initManagementSchema(ctx context.Context) error {
-	_, err := s.adminDB.ExecContext(ctx, `
-CREATE TABLE IF NOT EXISTS tenant_credentials (
-namespace   TEXT PRIMARY KEY,
-pg_password TEXT NOT NULL,
-created_at  TIMESTAMPTZ DEFAULT now()
-)
-`)
-	return err
-}
-
-// EnsureTenantDB создаёт DATABASE, USER и таблицу iot_telemetry для namespace.
-// Идемпотентен — повторный вызов безопасен.
-// Вызывается mqtt-bridge при первом сообщении от нового tenant.
-func (s *IoTPostgresStore) EnsureTenantDB(ctx context.Context, namespace string) error {
-	dbName := tenantDBName(namespace)
-	userName := dbName
-
-	var exists bool
-	err := s.adminDB.QueryRowContext(ctx,
-		`SELECT EXISTS(SELECT 1 FROM pg_database WHERE datname = $1)`, dbName,
-	).Scan(&exists)
-	if err != nil {
-		return fmt.Errorf("iotpg: check tenant DB %s: %w", dbName, err)
-	}
-
-	if !exists {
-		password := uuid.New().String()
-
-		// CREATE USER через DO block — pg не поддерживает CREATE USER IF NOT EXISTS
-		_, err = s.adminDB.ExecContext(ctx, fmt.Sprintf(
-			`DO $$ BEGIN
-                IF NOT EXISTS (SELECT FROM pg_roles WHERE rolname = '%s') THEN
-                    CREATE USER %s WITH PASSWORD '%s';
-                END IF;
-            END $$`, userName, userName, password,
-		))
-		if err != nil {
-			return fmt.Errorf("iotpg: create user %s: %w", userName, err)
-		}
-
-		// CREATE DATABASE нельзя в транзакции
-		if _, err = s.adminDB.ExecContext(ctx,
-			fmt.Sprintf(`CREATE DATABASE %s OWNER %s`, dbName, userName),
-		); err != nil {
-			return fmt.Errorf("iotpg: create database %s: %w", dbName, err)
-		}
-
-		if _, err = s.adminDB.ExecContext(ctx,
-			`INSERT INTO tenant_credentials (namespace, pg_password) VALUES ($1, $2)
- ON CONFLICT (namespace) DO NOTHING`,
-			namespace, password,
-		); err != nil {
-			return fmt.Errorf("iotpg: save credentials %s: %w", namespace, err)
-		}
-		s.log.Info("iotpg: created tenant DB", "namespace", namespace, "db", dbName)
-	}
-
-	// Создаём таблицу в tenant DB (суперюзер имеет доступ)
-	tenantDB, err := s.getTenantDB(ctx, namespace)
-	if err != nil {
-		return err
-	}
-	_, err = tenantDB.ExecContext(ctx, `
-CREATE TABLE IF NOT EXISTS iot_telemetry (
-id        BIGSERIAL PRIMARY KEY,
-device_id TEXT        NOT NULL,
-ts        TIMESTAMPTZ NOT NULL DEFAULT now(),
-payload   JSONB       NOT NULL
-);
-CREATE INDEX IF NOT EXISTS idx_iot_telemetry_device_ts
-ON iot_telemetry (device_id, ts DESC);
-`)
-	return err
-}
-
-// InsertTelemetry записывает строку телеметрии в tenant DB.
-func (s *IoTPostgresStore) InsertTelemetry(ctx context.Context, namespace, deviceID string, payload json.RawMessage) error {
-	tenantDB, err := s.getTenantDB(ctx, namespace)
-	if err != nil {
-		return fmt.Errorf("iotpg: get tenant DB for insert: %w", err)
-	}
-	_, err = tenantDB.ExecContext(ctx,
-		`INSERT INTO iot_telemetry (device_id, payload) VALUES ($1, $2)`,
-		deviceID, []byte(payload),
-	)
-	return err
-}
-
-// QueryTelemetry читает телеметрию из tenant DB (ts DESC).
-// deviceID — фильтр (пустая строка = все устройства). limit — max записей (50..1000).
-// Если tenant DB не существует (данных ещё нет) — возвращает пустой срез без ошибки.
-func (s *IoTPostgresStore) QueryTelemetry(ctx context.Context, namespace, deviceID string, limit int) ([]TelemetryRow, error) {
-	if limit <= 0 {
-		limit = 50
-	}
-	if limit > 1000 {
-		limit = 1000
-	}
-	tenantDB, err := s.getTenantDB(ctx, namespace)
-	if err != nil {
-		// Если DB не существует — тенант ещё не отправлял данные, это нормально
-		if isDBNotExistErr(err) {
-			return []TelemetryRow{}, nil
-		}
-		return nil, fmt.Errorf("iotpg: get tenant DB for query: %w", err)
-	}
-
-	var rows *sql.Rows
-	if deviceID != "" {
-		rows, err = tenantDB.QueryContext(ctx,
-			`SELECT id, device_id, ts, payload FROM iot_telemetry
- WHERE device_id = $1 ORDER BY ts DESC LIMIT $2`,
-			deviceID, limit,
-		)
-	} else {
-		rows, err = tenantDB.QueryContext(ctx,
-			`SELECT id, device_id, ts, payload FROM iot_telemetry
- ORDER BY ts DESC LIMIT $1`,
-			limit,
-		)
-	}
-	if err != nil {
-		return nil, fmt.Errorf("iotpg: query telemetry for %s: %w", namespace, err)
-	}
-	defer rows.Close()
-
-	var result []TelemetryRow
-	for rows.Next() {
-		var r TelemetryRow
-		var rawPayload []byte
-		if err := rows.Scan(&r.ID, &r.DeviceID, &r.Ts, &rawPayload); err != nil {
-			return nil, fmt.Errorf("iotpg: scan row: %w", err)
-		}
-		r.Payload = json.RawMessage(rawPayload)
-		result = append(result, r)
-	}
-	return result, rows.Err()
-}
-
-// TenantPGStats — статистика телеметрии одного tenant за разные периоды.
-type TenantPGStats struct {
-	Namespace string         `json:"namespace"`
-	DBName    string         `json:"db_name"`
-	Total     int64          `json:"total"`
-	Last1h    int64          `json:"last_1h"`
-	Last24h   int64          `json:"last_24h"`
-	Latest    []TelemetryRow `json:"latest"`
-	Error     string         `json:"error,omitempty"`
-}
-
-// PostgresAdminStats — агрегированная статистика по всем tenant для страницы администратора.
-type PostgresAdminStats struct {
-	Tenants   []TenantPGStats `json:"tenants"`
-	TotalAll  int64           `json:"total_all"`
-	Reachable bool            `json:"reachable"`
-}
-
-// GetAdminStats собирает статистику по всем tenant из management DB.
-// Используется только страницей администратора — не для tenant API.
-func (s *IoTPostgresStore) GetAdminStats(ctx context.Context) (*PostgresAdminStats, error) {
-	// Список всех тенантов из management DB
-	nsRows, err := s.adminDB.QueryContext(ctx, `SELECT namespace FROM tenant_credentials ORDER BY namespace`)
-	if err != nil {
-		return nil, fmt.Errorf("iotpg: list tenants: %w", err)
-	}
-	defer nsRows.Close()
-
-	var namespaces []string
-	for nsRows.Next() {
-		var ns string
-		if err := nsRows.Scan(&ns); err != nil {
-			return nil, err
-		}
-		namespaces = append(namespaces, ns)
-	}
-	if err := nsRows.Err(); err != nil {
-		return nil, err
-	}
-
-	result := &PostgresAdminStats{
-		Reachable: true,
-		Tenants:   make([]TenantPGStats, 0, len(namespaces)),
-	}
-
-	for _, ns := range namespaces {
-		stats := TenantPGStats{
-			Namespace: ns,
-			DBName:    tenantDBName(ns),
-		}
-
-		tenantDB, err := s.getTenantDB(ctx, ns)
-		if err != nil {
-			stats.Error = err.Error()
-			result.Tenants = append(result.Tenants, stats)
-			continue
-		}
-
-		// Counts: total, last 1h, last 24h — одним запросом
-		err = tenantDB.QueryRowContext(ctx, `
-SELECT
-  COUNT(*),
-  COUNT(*) FILTER (WHERE ts > NOW() - INTERVAL '1 hour'),
-  COUNT(*) FILTER (WHERE ts > NOW() - INTERVAL '24 hours')
-FROM iot_telemetry`).Scan(&stats.Total, &stats.Last1h, &stats.Last24h)
-		if err != nil {
-			stats.Error = err.Error()
-			result.Tenants = append(result.Tenants, stats)
-			continue
-		}
-		result.TotalAll += stats.Total
-
-		// Последние 5 сообщений для предпросмотра
-		latestRows, err := tenantDB.QueryContext(ctx,
-			`SELECT id, device_id, ts, payload FROM iot_telemetry ORDER BY ts DESC LIMIT 5`)
-		if err == nil {
-			defer latestRows.Close()
-			for latestRows.Next() {
-				var r TelemetryRow
-				var rawPayload []byte
-				if err := latestRows.Scan(&r.ID, &r.DeviceID, &r.Ts, &rawPayload); err == nil {
-					r.Payload = json.RawMessage(rawPayload)
-					stats.Latest = append(stats.Latest, r)
-				}
-			}
-		}
-
-		result.Tenants = append(result.Tenants, stats)
-	}
-
-	return result, nil
-}
-
-// isDBNotExistErr проверяет что ошибка — «database does not exist» (PostgreSQL code 3D000).
-// Используется в QueryTelemetry: если DB нет — просто нет данных, не ошибка системы.
-func isDBNotExistErr(err error) bool {
-	var pqErr *pq.Error
-	if errors.As(err, &pqErr) {
-		// 3D000 = invalid_catalog_name (база данных не существует)
-		return pqErr.Code == "3D000"
-	}
-	return false
-}
-
-// Close закрывает все подключения (admin + tenant кэш).
-func (s *IoTPostgresStore) Close() error {
-	s.tenants.Range(func(_, value any) bool {
-		if db, ok := value.(*sql.DB); ok {
-			db.Close()
-		}
-		return true
-	})
-	return s.adminDB.Close()
-}
-
-// getTenantDB возвращает *sql.DB для tenant DB из кэша или открывает новый.
-func (s *IoTPostgresStore) getTenantDB(ctx context.Context, namespace string) (*sql.DB, error) {
-	if cached, ok := s.tenants.Load(namespace); ok {
-		return cached.(*sql.DB), nil
-	}
-	dsn := replaceDSNDatabase(s.adminDSN, tenantDBName(namespace))
-	db, err := sql.Open("postgres", dsn)
-	if err != nil {
-		return nil, fmt.Errorf("iotpg: open tenant DB %s: %w", tenantDBName(namespace), err)
-	}
-	pingCtx, cancel := context.WithTimeout(ctx, 5*time.Second)
-	defer cancel()
-	if err := db.PingContext(pingCtx); err != nil {
-		db.Close()
-		return nil, fmt.Errorf("iotpg: ping tenant DB %s: %w", tenantDBName(namespace), err)
-	}
-	db.SetMaxOpenConns(5)
-	db.SetMaxIdleConns(2)
-	db.SetConnMaxLifetime(5 * time.Minute)
-
-	actual, loaded := s.tenants.LoadOrStore(namespace, db)
-	if loaded {
-		db.Close()
-		return actual.(*sql.DB), nil
-	}
-	return db, nil
-}
-
-// replaceDSNDatabase заменяет имя базы данных в DSN.
-// Вход:  "postgresql://user:pass@host:5432/iot_platform?sslmode=disable"
-// Выход: "postgresql://user:pass@host:5432/tenant_abc?sslmode=disable"
-func replaceDSNDatabase(dsn, newDBName string) string {
-	schemeEnd := strings.Index(dsn, "://")
-	if schemeEnd < 0 {
-		return dsn
-	}
-	hostPart := dsn[schemeEnd+3:]
-	slashIdx := strings.LastIndex(hostPart, "/")
-	if slashIdx < 0 {
-		return dsn
-	}
-	afterSlash := hostPart[slashIdx+1:]
-	suffix := ""
-	if qIdx := strings.Index(afterSlash, "?"); qIdx >= 0 {
-		suffix = afterSlash[qIdx:]
-	}
-	prefix := dsn[:schemeEnd+3+slashIdx+1]
-	return prefix + newDBName + suffix
-}
-
-// tenantDBName возвращает имя Postgres DATABASE для namespace.
-// Дефисы заменяются на подчёркивания (pg не поддерживает дефисы в unquoted именах).
-// Пример: "sless-abc123" → "tenant_sless_abc123"
-func tenantDBName(namespace string) string {
-	return "tenant_" + strings.ReplaceAll(namespace, "-", "_")
-}
@@ -1,99 +0,0 @@
-// Создано: 2026-04-04
-// Описание CRD IoTDevice — регистрация IoT-устройства в платформе sless.
-// Пользователь создаёт IoTDevice, контроллер автоматически генерирует MQTT-credentials
-// и сохраняет их в k8s Secret в том же namespace.
-// При удалении IoTDevice — Secret удаляется каскадно через OwnerReference.
-
-package v1alpha1
-
-import (
-	metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
-)
-
-// IoTDeviceSpec — желаемое состояние IoT-устройства.
-type IoTDeviceSpec struct {
-	// DeviceID — уникальный идентификатор устройства внутри namespace.
-	// Используется как часть MQTT username и имени Secret.
-	// Разрешены только строчные буквы, цифры и дефис — для совместимости с k8s именами.
-	// +kubebuilder:validation:Required
-	// +kubebuilder:validation:Pattern=`^[a-z0-9][a-z0-9-]*[a-z0-9]$`
-	// +kubebuilder:validation:MaxLength=48
-	DeviceID string `json:"deviceId"`
-
-	// Metadata — произвольные метаданные устройства (модель, локация и т.д.).
-	// Хранятся только в CRD, не влияют на логику контроллера.
-	// +optional
-	Metadata map[string]string `json:"metadata,omitempty"`
-
-	// Enabled — активно ли устройство (может подключаться к MQTT).
-	// Если false — контроллер устанавливает phase=Disabled, EMQX auth отклоняет подключение.
-	// Secret с credentials НЕ удаляется — при re-enable пароль остаётся прежним.
-	// +kubebuilder:default=true
-	Enabled bool `json:"enabled"`
-}
-
-// IoTDevicePhase — текущая фаза жизненного цикла устройства.
-type IoTDevicePhase string
-
-const (
-	// IoTDevicePhaseActive — устройство активно, credentials выданы, может подключаться к MQTT.
-	IoTDevicePhaseActive IoTDevicePhase = "Active"
-	// IoTDevicePhaseDisabled — устройство отключено (spec.enabled=false). EMQX отклоняет подключения.
-	IoTDevicePhaseDisabled IoTDevicePhase = "Disabled"
-	// IoTDevicePhasePending — устройство создано, контроллер ещё не успел сгенерировать credentials.
-	IoTDevicePhasePending IoTDevicePhase = "Pending"
-	// IoTDevicePhaseError — ошибка при создании credentials (см. status.message).
-	IoTDevicePhaseError IoTDevicePhase = "Error"
-)
-
-// IoTDeviceStatus — наблюдаемое состояние IoT-устройства (заполняет контроллер).
-type IoTDeviceStatus struct {
-	// Phase — текущее состояние: Active, Disabled, Pending, Error.
-	Phase IoTDevicePhase `json:"phase,omitempty"`
-
-	// MQTTUsername — имя пользователя для подключения к MQTT-брокеру.
-	// Формат: {namespace}_{deviceId} — глобально уникален в рамках EMQX.
-	MQTTUsername string `json:"mqttUsername,omitempty"`
-
-	// SecretName — имя k8s Secret в том же namespace, содержащего mqtt-username и mqtt-password.
-	SecretName string `json:"secretName,omitempty"`
-
-	// TopicPrefix — MQTT topic prefix, на который разрешена публикация.
-	// Формат: {namespace}/ — устройство не может публиковать в чужие namespace.
-	TopicPrefix string `json:"topicPrefix,omitempty"`
-
-	// LastConnected — время последнего MQTT-подключения устройства.
-	// Заполняется MQTT auth-сервисом при каждом успешном CONNECT.
-	// +optional
-	LastConnected *metav1.Time `json:"lastConnected,omitempty"`
-
-	// Message — человекочитаемое сообщение о текущем статусе или ошибке.
-	Message string `json:"message,omitempty"`
-}
-
-// +kubebuilder:object:root=true
-// +kubebuilder:subresource:status
-// +kubebuilder:printcolumn:name="DeviceID",type=string,JSONPath=`.spec.deviceId`
-// +kubebuilder:printcolumn:name="Phase",type=string,JSONPath=`.status.phase`
-// +kubebuilder:printcolumn:name="Enabled",type=boolean,JSONPath=`.spec.enabled`
-// +kubebuilder:printcolumn:name="MQTTUser",type=string,JSONPath=`.status.mqttUsername`
-// +kubebuilder:printcolumn:name="Age",type=date,JSONPath=`.metadata.creationTimestamp`
-
-// IoTDevice — ресурс для регистрации IoT-устройства в платформе.
-// Контроллер автоматически создаёт k8s Secret с MQTT-credentials.
-type IoTDevice struct {
-	metav1.TypeMeta   `json:",inline"`
-	metav1.ObjectMeta `json:"metadata,omitempty"`
-
-	Spec   IoTDeviceSpec   `json:"spec,omitempty"`
-	Status IoTDeviceStatus `json:"status,omitempty"`
-}
-
-// +kubebuilder:object:root=true
-
-// IoTDeviceList — список IoTDevice объектов.
-type IoTDeviceList struct {
-	metav1.TypeMeta `json:",inline"`
-	metav1.ListMeta `json:"metadata,omitempty"`
-	Items           []IoTDevice `json:"items"`
-}
--- a/Show More
+++ b/Show More
				`@@ -1 +0,0 @@`
				`# нет внешних зависимостей`