orchestrator/docs/work-items/ORCH-061/07-infra-requirements.md

07 — Требования к инфраструктуре: ORCH-061

Work Item: ORCH-061 · Репо: orchestrator

Топология/контейнеры/порты не меняются (TRZ §3, §9). Self-hosting-безопасность сохранена: прод-контейнер orchestrator (8500) не перезапускается/не роняется в рамках задачи; любые сборки/recreate — только staging (8501). См. docs/operations/INFRA.md.

IR-1 — Конфиг-флаг (kill-switch)

Новый флаг staging_infra_tolerance_enabled (env ORCH_STAGING_INFRA_TOLERANCE_ENABLED, дефолт true).

• Должен присутствовать в окружении контейнера orchestrator-staging (.env.staging), т.к. scripts/staging_check.py читает его через src.config.settings при каноническом запуске docker exec внутри стенда.
• Для прод-инстанса (.env) флаг безвреден (на прод-пути staging-suite не исполняется), но рекомендуется держать значения консистентными.
• false → мгновенный возврат к строгому (legacy) поведению без передеплоя кода.
• Канон секретов/env: значения в .env/.env.staging на хосте, в гит НЕ коммитятся; задокументировать ключ в .env.example (канон ORCH-9).

IR-2 — Опциональное hardening sandbox (направление «а», НЕ блокер)

Первопричина ложных C9a/C9b — bot-аккаунты агентов (ORCH_PLANE_BOT_*) не добавлены членами Plane-проекта SANDBOX (8c5a3025-…), созданного после провижининга ботов. С выбранным механизмом (б) это перестаёт блокировать конвейер, но честный 10/10 в sandbox желателен:

• Добавить bot-аккаунты агентов членами SANDBOX-проекта в Plane (даст честный C9b: коммент analyst'а перестанет получать 403; и устранит инфра-причину C9a/C9b).
• Действие — ручное (Plane-admin), вне автоматической досягаемости таска; выполняется оператором при возможности. После него C9a/C9b проходят честно и waiver не нужен.
• Это hardening, а не требование приёмки ORCH-061 (приёмка — на механизме «б»).

IR-3 — Без новой инфраструктуры

Новые сервисы/порты/тома/сетевые правила/cron — не требуются. Никаких изменений в docker-compose.yml, образах, реестре проектов.