Deploy shared-sqs v0.1.22

deployments/k8s/deployment.yaml

@@ -1,6 +1,6 @@
 # deployments/k8s/deployment.yaml
 # Deployment shared-sqs — strategy RollingUpdate (теперь возможен т.к. Redis хранит состояние)
-# Updated: 2026-04-10 — v0.1.17: security fixes (20 vulnerabilities), AWS-compatible limits
+# Updated: 2026-04-12 09:57 MSK — image v0.1.22 для demo UI showcase mode
 apiVersion: apps/v1
 kind: Deployment
 metadata:
@@ -25,7 +25,7 @@ spec:
     spec:
       containers:
       - name: shared-sqs
-        image: naeel/shared-sqs:v0.1.17
+        image: naeel/shared-sqs:v0.1.22
         ports:
         - containerPort: 4100
           name: http

doc/errors/helm-upgrade-conflict-2026-04-12.md

@@ -0,0 +1,26 @@
+# Ошибка: Helm upgrade conflict на поле image у shared-sqs
+
+Дата: 2026-04-12
+Агент: GitHub Copilot (GPT-5.4)
+
+## Симптом
+
+Команда `helm upgrade --install shared-sqs deployments/helm/shared-sqs -n shared-sqs` завершилась ошибкой:
+
+`conflict with "kubectl-set" using apps/v1: .spec.template.spec.containers[name="shared-sqs"].image`
+
+## Причина
+
+Поле image у Deployment ранее менялось через `kubectl set image`, поэтому менеджер поля для этого участка объекта стал `kubectl-set`. При следующем Helm upgrade server-side apply упёрся в conflict на том же поле.
+
+## Что сделано
+
+- image `naeel/shared-sqs:v0.1.22` был собран и запушен;
+- live deployment обновлён командой `kubectl -n shared-sqs set image deployment/shared-sqs shared-sqs=naeel/shared-sqs:v0.1.22`;
+- rollout успешно завершился;
+- live validation прошла: demo token работает, `tests/quick_test.sh` → `31/31 PASS`.
+
+## Что учитывать дальше
+
+- при следующем нормальном выравнивании Helm release нужно убрать field-manager conflict;
+- до этого Helm chart и values уже обновлены на `v0.1.22`, но live image был переключён прямым `kubectl set image`.

doc/progress.md

@@ -2,6 +2,15 @@
 
 ## Версия v0.1.x
 
+### v0.1.22 (2026-04-12) — demo UI showcase mode deployed
+- ✅ Demo UI token поддержан сервером: `demo-ui-shared-sqs-ngcloud-2026`
+- ✅ Реальный JWT login сохранён без изменений
+- ✅ UI API ограничен текущим tenant-ом, без обзора всех tenant-ов
+- ✅ Собран и запушен image `naeel/shared-sqs:v0.1.22`
+- ✅ Live deployment обновлён до `naeel/shared-sqs:v0.1.22`
+- ✅ Live smoke validation: `bash tests/quick_test.sh` → `31/31 PASS`
+- ✅ Demo token на live `/ui/api/auth` возвращает demo tenant `t-demo-shared-sqs-ngcloud`
+
 ### v0.1.22-dev (2026-04-12) — demo UI login + UI tenant scoping
 - ✅ Добавлен публичный UI demo token: `demo-ui-shared-sqs-ngcloud-2026`
 - ✅ Demo token маппится на уже сидированный demo tenant `t-demo-shared-sqs-ngcloud`

doc/thinking/2026-04-12.md

@@ -281,6 +281,39 @@
 - Не менял SQS auth path для AWS CLI.
 - Не пытался превращать UI в полноценную admin console и пользовательскую console одновременно: для UI выбрал явный user/demo режим с одним tenant-ом.
 
+---
+# Agent: GitHub Copilot (GPT-5.4)
+
+## Задача: перепроверить live-стенд и довести deploy до рабочего состояния
+
+### Что проверял
+После жалобы на `invalid JWT: expected 3 parts, got 1` я не стал объяснять по памяти, а перепроверил три вещи по факту:
+
+1. В `main` уже есть demo UI код.
+2. В кластере реально был запущен образ `naeel/shared-sqs:v0.1.21`.
+3. Live `POST /ui/api/auth` на demo token действительно отвечал старой JWT-ошибкой.
+
+### Вывод
+Проблема была не в коде ветки и не в браузере, а в том, что стенд ещё не был выкатан на новый образ.
+
+### Что сделал
+1. Обновил version surfaces до `v0.1.22` в deploy/helm файлах.
+2. Собрал и запушил `naeel/shared-sqs:v0.1.22`.
+3. Попытался выкатить через Helm.
+4. Helm upgrade упёрся в field-manager conflict на поле image (`kubectl-set` vs Helm).
+5. Чтобы не тратить время на долгую reconcile-разборку прямо посреди проверки стенда, переключил live deployment через `kubectl set image`.
+6. Дождался успешного rollout.
+7. Перепроверил live demo auth и потом прогнал `bash tests/quick_test.sh` против `https://qu.kube5s.ru`.
+
+### Итог
+- live deployment теперь на `naeel/shared-sqs:v0.1.22`;
+- demo token работает;
+- реальный JWT flow не сломан;
+- `quick_test.sh` дал `31/31 PASS`.
+
+### Почему этот путь был правильным
+Пользователь явно потребовал не рассказывать, а сначала всё перепроверять и доводить до рабочего состояния. Поэтому после обнаружения расхождения между `main` и live-стендом я не остановился на объяснении, а довёл цепочку до фактического результата на боевом endpoint.
+
 ---
 
 ## Внешние ссылки для возврата к теме 64KB+