chore: initial import from sless/shared-sqs (v0.1.14)

- Standalone SQS-service repository
- Multi-tenant message queue service, AWS SQS compatible
- Based on GoAws, with mutable tenants, auth, WebUI, Redis persistence
- Ready for independent development and deployment
- See doc/ and README.md for architecture and usage

doc/thinking/2026-04-10.md

@@ -0,0 +1,90 @@
+# 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.