# 07 — Требования к инфраструктуре (ORCH-043)

## Вывод: топология не меняется. Новых контейнеров/портов/сервисов нет.

| Аспект | Требование |
|--------|-----------|
| Контейнеры | Без изменений. Прод `orchestrator` (8500) и `orchestrator-staging` (8501) — как есть. |
| Порты | Без изменений. |
| Сеть/внешние сервисы | Без новых зависимостей. Используются существующие git/Gitea (fetch/push) и pytest. |
| Файловая система | Новый артефакт времени выполнения — lease-файл `<repos_dir>/.merge-lease-<repo>.json` (см. `08-data-requirements.md`). Лежит в уже примонтированном `repos_dir` (`/repos`). Дополнительного volume не требуется. |
| Worktree | Переиспользуется существующая изоляция (`/repos/_wt/<repo>/<branch>`, ORCH-2). Все git-операции merge-gate — в worktree. |
| `.env` / compose / прод-инфра | **НЕ изменяются** (AC-14). Новые `ORCH_*` настройки имеют безопасные дефолты (см. ADR-001 §6) и документируются в `.env.example`. |

## Эксплуатационные требования
- **git push прав** для оркестратора достаточно существующих (он уже пушит ветки/PR-артефакты).
  Merge-gate пушит ТОЛЬКО ветку задачи (`--force-with-lease`), `main` — никогда.
- **Раскат поэтапно**: `merge_gate_enabled=False` или пустой `merge_gate_repos` (реален
  только для `orchestrator`) позволяют включать гейт постепенно без риска для чужих репо.
- **Self-hosting-страховка сохранена**: изменения ORCH-043 проходят обязательную стадию
  `deploy-staging` (8501) до прод-деплоя самого оркестратора; прод-контейнер не рестартится
  в рамках задачи.

## Рекомендация по процессу
Изменение сквозное (новый QG + поведение ребра `deploy-staging → deploy`) →
рекомендуется лейбл `arch:major-change`. Прод-деплой ORCH-043 — строго через staging-гейт.