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, уже есть).

3.9 KiB Raw Permalink Blame History Unescape Escape