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

## Топология — без изменений
Новой топологии не вводится. Прод `orchestrator` (8500) и staging (8501) — как есть.
Merge выполняется детерминированным кодом в уже существующем restart-surviving Phase C
finalizer (новый контейнер после рестарта), без новых сервисов/портов/контейнеров.

## I-1. Gitea токен с правом merge PR (предусловие)
Merge-актор `merge_gate.merge_pr` вызывает `POST /repos/{owner}/{repo}/pulls/{index}/merge`
через существующий клиент и `settings.gitea_token` / `settings.gitea_url` / `settings.gitea_owner`.
- Требование: тот же `gitea_token`, которым агент `deployer` сегодня мержит PR в `main`,
  ДОЛЖЕН иметь право write/merge на репо `orchestrator`. Так как deployer уже мержит этим
  токеном — **новых прав, как правило, не требуется** (тот же токен, тот же путь API).
- Действие при раскате: убедиться, что бот-токен — член/коллаборатор репо `orchestrator`
  с правом merge (иначе merge_pr вернёт HTTP-ошибку → never-raise → HOLD+alert, не падение).

## I-2. Сетевой доступ контейнера к Gitea
Контейнер прода уже ходит в Gitea API (`pr_already_merged`, webhooks). Дополнительного
сетевого доступа не нужно. При недоступности Gitea verify консервативно даёт «не
подтверждено» → HOLD+alert (fail-closed для `done`).

## I-3. Доступ к `origin/main` из worktree задачи
Верификатор делает `git fetch origin main` + `git merge-base --is-ancestor <sha> origin/main`
в worktree задачи (как `image_freshness`/merge-gate уже делают `git fetch`/`rebase`).
Предусловие — рабочий git-remote `origin` в worktree (есть сегодня). Ошибка fetch →
never-raise → `False` → HOLD+alert.

## I-4. Конфигурация (env, дефолты безопасны)
| Флаг | Дефолт | Назначение |
|------|--------|------------|
| `ORCH_MERGE_VERIFY_ENABLED` | `true` | kill-switch; `false` → строго прежнее поведение (1:1 до фикса) |
| `ORCH_MERGE_VERIFY_REPOS` | `""` | CSV; пусто → только self-hosting (`orchestrator`) |
| `ORCH_MERGE_PR_TIMEOUT_S` (опц.) | напр. 30 | таймаут merge-вызова Gitea |
| `ORCH_MERGE_VERIFY_TIMEOUT_S` (опц.) | напр. 60 | таймаут git fetch/merge-base |

Дефолты не требуют изменения `.env` для штатного раската (область = self-hosting).
Откатить фикс мгновенно можно `ORCH_MERGE_VERIFY_ENABLED=false`.

## I-5. Раскат через staging-гейт (self-hosting safety)
Изменение касается self-deploy пути орка → раскат ОБЯЗАН пройти стадию `deploy-staging`
(8501) перед прод-деплоем (CLAUDE.md §self-hosting). Прод-деплой — только переводом задачи
в статус `Confirm Deploy` (ORCH-059), ручной approve сохранён (INV-3). Никаких рестартов
прода в рамках разработки/ревью.

## I-6. Без миграции БД
Schema-changes запрещены. Restart-safe состояние нового шага — существующие sentinel'ы
`.deploy-state-<repo>/<wi>/` + очередь `jobs` (колонка `jobs.pid`, ORCH-065, уже есть).