wiki/memory/2026-06-04.md

📋 ORCH-30 создана: тестовые среды (test/staging) для конвейера

• Слава голосом: где происходит тестирование? Нужна тестовая среда (не dev/не prod) для прогона функционала тестером «как будто прод». Для orchestrator И для enduro-trails. Просил записать анализ в задачу Plane.
• Проверила на проде — Слава ПРАВ, тестовых сред НЕТ:
  • enduro-trails: 1 контейнер enduro-trails-app-1 (5556), деплой = enduro-deploy-hook.sh (git pull + compose up на тот же контейнер) → сразу PROD.
  • orchestrator: 1 контейнер, деплой-хука вообще нет.
  • Тестируется только CI (pytest на push) — это юнит-тесты в чистом job, НЕ живой функционал. Стадия testing есть, но тестеру прогонять не на чем.
  • Деплой = первый запуск нового кода сразу в прод. Для self-hosting orchestrator опасно вдвойне (оркестратор кладёт сам себя).
• Записала в ORCH-30 (id 85da2b10-6dc4-4693-b611-e96c6117f565, seq 30, Backlog): анализ + 3 варианта (A эфемерный CI-стенд / B постоянный staging / C гибрид — рекомендую) + правки методики (стадия deploy-staging ПЕРЕД deploy-prod, тестер на staging-эндпоинт, build-once-promote, seed-фикстуры) + 5 открытых вопросов Славе. Связь: блокирует ORCH-7, пересекается с ORCH-21.
• Грабли Plane API (запомнить): env ORCH_PLANE_API_URL=http://localhost:8091 БЕЗ /api/v1 — суффикс добавляет код (plane_sync.py:15 PLANE_BASE=f"{url}/api/v1"). Если дёргать API вручную — добавлять /api/v1 самой, иначе Plane вернёт HTML (200) вместо JSON. Заголовок X-API-Key. Скрипт лить в контейнер orchestrator через base64-stdin+docker cp (scp на воркстейшене НЕТ, прямого доступа к localhost:8091 из контейнера ассистента НЕТ).
• enduro-deploy-hook УЖЕ умеет rollback (PREV_IMG) — пригодится для ORCH-21/staging.

🏗️ Staging-среда orchestrator — дизайн согласован, 5 задач заведены (04.06)

• Решения Славы: (1) постоянный staging-контейнер, (2) полная изоляция БД, (3) вариант b (песочница: тестовый Plane-проект + Gitea-репо), (4) промоут — на усмотрение Стрим («автономно и надёжно»), (5) не только smoke — реальные прогоны/статусы/комменты Plane + проверка доступов + интеграционное тестирование. (6) агенты = гибрид C (заглушки по дефолту + full-real по флагу). (7) approve — ручной на старте.
• Ключевой принцип (решение Стрим): деплоем орка рулит ВНЕШНИЙ хост-хук, НЕ сам контейнер (иначе убивает себя на середине self-деплоя). Рубильник снаружи.
• Дизайн: tasks/orchestrator/DESIGN_STAGING_ENV.md
• Задачи (все в Backlog, НЕ запускать — пайплайн стартует только при In Progress):
  • ORCH-31 (5a68a13c-3f3b-4d9e-91f7-24b0794bed06) — staging-инфра (контейнер 8501, изолир. БД)
  • ORCH-32 (3dadcf0d-f1b6-4302-8075-8d428ace01f6) — песочница Plane+Gitea
  • ORCH-33 (a11a7c0f-a78a-4309-9aa5-1c43d4355d0f) — тест-сьют (smoke+доступы+e2e)
  • ORCH-34 (47fe9e75-d7ff-4ecb-bb99-67af9b23ab67) — хост-деплой-хук + promote + auto-rollback (ядро, пересекается с ORCH-21)
  • ORCH-35 (4ead9be7-e1bf-4a28-8c76-88bda1c1fc2c) — встройка в методику (deploy-staging перед deploy-prod)
• Backlog state id ORCH: 2d5d42ff-e94d-4209-a664-8020c28c2a95
• Слава: «делай все этапы, минимум вопросов, installer skill если нужно, следи чтобы задачи случайно не запустились».