docs(ORCH-009): staging gate log — SUCCESS (8/10, C9a/C9b infra-waived)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

.env.example

@@ -5,68 +5,14 @@ ORCH_PLANE_API_URL=http://plane-app-api-1:8000
 ORCH_PLANE_WEB_URL=
 ORCH_PLANE_API_TOKEN=
 ORCH_PLANE_WORKSPACE_SLUG=
-# Webhook secrets are GENERATED PER HOST: python3 scripts/gen_secrets.py
-# (ORCH-101 / AC-5: production secrets are NEVER copied to a new host).
 ORCH_PLANE_WEBHOOK_SECRET=
 ORCH_GITEA_URL=http://localhost:3000
-# External (browser) URL of Gitea for clickable Branch/PR links in comments;
-# empty -> falls back to ORCH_GITEA_URL.
-ORCH_GITEA_PUBLIC_URL=
 ORCH_GITEA_TOKEN=
 ORCH_GITEA_WEBHOOK_SECRET=
-ORCH_GITEA_OWNER=admin
-# Per-agent Plane bot tokens (optional): when set, comments are posted under
-# the matching bot so Plane shows the real author; empty -> ORCH_PLANE_API_TOKEN.
-ORCH_PLANE_BOT_ANALYST=
-ORCH_PLANE_BOT_ARCHITECT=
-ORCH_PLANE_BOT_DEVELOPER=
-ORCH_PLANE_BOT_REVIEWER=
-ORCH_PLANE_BOT_TESTER=
-ORCH_PLANE_BOT_DEPLOYER=
-ORCH_PLANE_BOT_STREAM=
-# Telegram live-tracker / alerts (empty -> notifications are logged, not sent).
-ORCH_TELEGRAM_BOT_TOKEN=
-ORCH_TELEGRAM_CHAT_ID=
-# ORCH-6: project registry — JSON array of {plane_project_id, repo,
-# work_item_prefix, name}. Empty -> built-in default registry (src/projects.py)
-# whose Plane UUIDs belong to the ORIGINAL host. On a NEW host this key is
-# MANDATORY (ORCH-101 replication checklist, docs/operations/REPLICATION.md).
-ORCH_PROJECTS_JSON=
 ORCH_CLAUDE_BIN=/usr/bin/claude
+ORCH_REPOS_DIR=/home/slin/repos
 ORCH_DB_PATH=/app/data/orchestrator.db
 
-# ── ORCH-101: host parametrization (replication foundation, ADR-001 D1–D7) ───
-# Every host-specific value lives HERE (defaults = the current production host;
-# an empty/absent value keeps behaviour 1:1). The same names are read by BOTH
-# pydantic Settings (env_file) and docker-compose ${VAR:-default} interpolation
-# (compose reads .env/shell, NOT a service's env_file). Full variable map and
-# the new-host procedure: docs/operations/REPLICATION.md.
-#   AGENT_HOME_DIR -> HOME of all actor subprocesses (agents/finalizer/monitor)
-#                     AND the target of the .claude/.claude.json/.ssh mounts AND
-#                     Dockerfile ARG APP_HOME (ORCH-040 group moves together).
-#   AGENT_GIT_NAME / GIT_EMAIL_DOMAIN -> git identity of agent commits; system
-#                     actors keep platform names deploy-finalizer/post-deploy-
-#                     monitor under the same domain.
-#   STAGING_PORT   -> staging instance port; image_freshness fail-closes when it
-#                     equals the prod port (ORCH-058 AC-9 guard).
-#   HOST_*         -> host-side sources of the bind mounts (repos, ~/.claude,
-#                     ~/.claude.json, ssh keydir, claude-code dist, node binary).
-#   RUN_UID/RUN_GID/DOCKER_GID -> container uid:gid + host docker group for
-#                     docker.sock access (group_add «МИНА 1», ORCH-040).
-ORCH_AGENT_HOME_DIR=/home/slin
-ORCH_AGENT_GIT_NAME=claude-bot
-ORCH_GIT_EMAIL_DOMAIN=mva154.local
-ORCH_STAGING_PORT=8501
-ORCH_HOST_REPOS_DIR=/home/slin/repos
-ORCH_HOST_CLAUDE_DIR=/home/slin/.claude
-ORCH_HOST_CLAUDE_JSON=/home/slin/.claude.json
-ORCH_HOST_SSH_DIR=/home/slin/.orchestrator-ssh
-ORCH_HOST_CLAUDE_CODE_DIR=/usr/lib/node_modules/@anthropic-ai/claude-code
-ORCH_HOST_NODE_BIN=/usr/bin/node
-ORCH_RUN_UID=1000
-ORCH_RUN_GID=1000
-ORCH_DOCKER_GID=999
-
 # ── Agent model / effort / fallback (ORCH-41, validation ORCH-74) ─────────────
 # Per-agent LLM model + reasoning effort, resolved by launcher.resolve_agent_*.
 # Resolution priority (per agent): project-override (projects_json agent_models/

.env.staging.example

@@ -36,14 +36,6 @@ ORCH_CLAUDE_BIN=/usr/bin/claude
 ORCH_REPOS_DIR=/repos
 ORCH_HOST_REPOS_DIR=/home/slin/repos
 
-# ── ORCH-101: host parametrization ───────────────────────────────────────────
-# The host keys (ORCH_AGENT_HOME_DIR / ORCH_AGENT_GIT_NAME / ORCH_GIT_EMAIL_DOMAIN /
-# ORCH_STAGING_PORT / ORCH_HOST_* / ORCH_RUN_* / ORCH_DOCKER_GID) default to the
-# current production host — set them ONLY on a new/different host (see
-# docs/operations/REPLICATION.md). NB: docker-compose ${VAR:-default}
-# interpolation reads the project .env / shell, NOT this env_file — values that
-# must reach compose (mounts/uid/ports) belong in .env, not here.
-
 # ── Database (ISOLATION KEY for staging) ─────────────────────────────────────
 # The staging volume mounts ./data/staging:/app/data, so the DB physically lives
 # at ./data/staging/orchestrator.db on the host — fully isolated from prod.

.env.watchdog.example

@@ -1,42 +0,0 @@
-# .env.watchdog — конфигурация sidecar-watchdog (контейнер orchestrator-watchdog).
-# Канонический example (ORCH-102, ADR-001 D5; симметрия .env.example/.env.staging.example).
-#
-# ⚠️ СЕМАНТИКА ФАЙЛА-НОСИТЕЛЯ: sidecar-контейнер читает ТОЛЬКО этот файл
-# (compose: env_file {path: .env.watchdog, required: false}). Ключ WATCHDOG_*,
-# положенный в .env, для sidecar ИНЕРТЕН (его видит лишь контейнер орка).
-# Отсутствие файла НЕ ломает `docker compose up` (required: false); нет токена →
-# fail-safe: watchdog пишет алерты в логи, но не отправляет.
-#
-# Создание на хосте: cp .env.watchdog.example .env.watchdog → заполнить два токена.
-# DO NOT COMMIT реальный .env.watchdog — этот файл только шаблон (зеркало
-# .env.staging.example); реальные значения живут на хосте.
-#
-# Нормативы:
-#   * C-1 (ORCH-100): у watchdog СВОЙ Telegram-бот — независимый канал алертов.
-#     Переиспользовать токен орка (ORCH_TELEGRAM_BOT_TOKEN) ЗАПРЕЩЕНО: упавший
-#     орк не сможет сообщить о себе своим же ботом.
-#   * Когерентность порта: WATCHDOG_METRICS_URL следует за прод-портом
-#     (ORCH_DEPLOY_PROD_TARGET_PORT) — сменил порт орка → обнови URL здесь.
-#   * Key-set этого файла = блок WATCHDOG_* в .env.example (канон ключей);
-#     синхронность держит tests/test_lite_setup_doc.py (key-sync, TC-02b).
-#     Значения = дефолты watchdog/config.py.
-
-WATCHDOG_ENABLED=true
-WATCHDOG_INTERVAL_S=30
-WATCHDOG_HTTP_TIMEOUT_S=5
-WATCHDOG_COOLDOWN_S=1800
-WATCHDOG_METRICS_URL=http://127.0.0.1:8500/metrics
-WATCHDOG_ORCH_DOWN_TICKS=3
-WATCHDOG_MEM_PCT=90
-WATCHDOG_DISK_CRIT_ENABLED=false
-WATCHDOG_DISK_CRIT_PCT=97
-WATCHDOG_DISK_PATHS=/repos,/app/data
-WATCHDOG_AGENT_HUNG_MIN=20
-WATCHDOG_AGENT_CPU_FLOOR=0.01
-WATCHDOG_STAGE_STUCK_MIN=120
-WATCHDOG_QUEUE_DEPTH=20
-WATCHDOG_CONTAINERS=orchestrator
-WATCHDOG_DOCKER_SOCK=/var/run/docker.sock
-WATCHDOG_DEPS=
-WATCHDOG_TG_BOT_TOKEN=
-WATCHDOG_TG_CHAT_ID=

.gitignore

@@ -7,10 +7,5 @@ data/
 .pytest_cache/
 # ORCH-31: staging env (secrets, not committed — see .env.staging.example)
 .env.staging
-# ORCH-102: sidecar-watchdog env (secrets, not committed — see .env.watchdog.example)
-.env.watchdog
 # ORCH-31: staging DB data directory
 data/staging/
-# ORCH-103: Bundled-тираж — локальные клоны репо bundle-инсталляции (целевой хост);
-# deploy/bundled/.env и deploy/bundled/data покрыты неякорными `.env` / `data/` выше
-deploy/bundled/repos/

.task-dev.md

@@ -1,4 +1,4 @@
-Work item: ORCH-103
+Work item: ORCH-100
 Repo: orchestrator
-Branch: feature/ORCH-103-orch-10b-bundled-bootstrap
+Branch: feature/ORCH-100-fnd-f1b-sidecar-watchdog
 Stage: development

CHANGELOG.md

@@ -3,30 +3,6 @@
 Формат: [Keep a Changelog](https://keepachangelog.com/). Записи — на смысловой PR/задачу.
 
 ## [Unreleased]
-- **ORCH-10b Bundled-тираж: весь стек одним комплектом + bootstrap-скрипт** (ORCH-103, `feat`): закрыт Type B эпика ORCH-10 — заказчик **без собственной инфраструктуры** получает конвейер «под ключ»: одна команда `docker compose -f deploy/bundled/docker-compose.yml up -d` поднимает весь стек (орк + watchdog + Gitea + зеркало upstream Plane CE ≈14 контейнеров), один прогон `scripts/bootstrap_bundle.py apply` доводит его до рабочего состояния. Рантайм байт-в-байт: `src/**`/корневой compose/`Dockerfile`/`STAGE_TRANSITIONS`/`QG_CHECKS`/схема БД — ноль изменений (паттерн ORCH-009/102, kill-switch не нужен — активация только явным запуском оператора на целевом хосте). ADR: `docs/work-items/ORCH-103/06-adr/ADR-001-bundled-stack-compose-and-bootstrap.md`, сквозной `adr-0038-bundled-replication-canon.md`.
-  - **Bundle-compose (D1–D4):** новый top-level каталог `deploy/` (дистрибутивы развёртывания); `deploy/bundled/docker-compose.yml` — один самодостаточный файл, project name `orchestrator-bundle` (узнаваемый префикс томов/контейнеров, по нему preflight детектирует «грязный хост»); `container_name` не пиннится (bundle и Lite не сталкиваются на одном хосте); staging-контура орка нет вовсе (self-hosting у заказчика = маршрут Lite). Все сторонние образы пиннованы неподвижными тегами (Plane CE v0.23.1 upstream-имена сервисов, Gitea 1.22.6, postgres/valkey/rabbitmq/minio). Сеть — одна bridge: машинный трафик строго сервис-DNS (`http://orchestrator:8500/webhook/plane|gitea`, `ORCH_GITEA_URL=http://gitea:3000`), наружу — только человеческие порты `BUNDLE_ORCH_PORT`/`BUNDLE_PLANE_PORT`/`BUNDLE_GITEA_HTTP_PORT`; postgres/redis/mq/minio не публикуются; мина Gitea закрыта `GITEA__webhook__ALLOWED_HOST_LIST=orchestrator`. Конфиг-канон — `deploy/bundled/.env.example` (только плейсхолдеры, ни одного дефолтного пароля; key-set-sync интерполяций держит тест); runtime-конфиг орка/watchdog — корневые `.env`/`.env.watchdog` (канон Lite 1:1, `env_file required: false` — первый `up` живёт до сборки конфига).
-  - **Bootstrap (D5–D8):** `scripts/bootstrap_bundle.py` — python stdlib-only (модули платформы не импортируются, держится ast-сканом), режимы `plan` (дефолт, ноль мутаций) / `apply` / `verify`, step-движок check→ensure (повторный запуск = каскад skip, resume после manual-step = повторный запуск), exit-контракт 0/2/1. Шаги: preflight (fail-fast ДО мутаций: docker/compose, порты, RAM/диск, чистота хоста по префиксу) → секреты (webhook — **строго** субпроцессом `gen_secrets.py`; bundle-креды — stdlib `secrets`; существующие не перетираются без `--force-secrets`; значения не печатаются) → up+готовность (healthchecks + poll, migrator exit 0) → init Gitea полностью автоматом (`gitea admin user create`/`generate-access-token`; branch protection НЕ настраивается — норматив D10 ORCH-009/INV-4) → init Plane (честные manual-step c API-верификацией результата; workspace-webhook — ensure с fallback на manual-step) → онбординг sandbox-проекта **строго** `onboard_project.py apply+verify` (нулевой дрейф канона статусов/лейблов) → git-доступ агентов HTTP token-remote (ssh-контур не вводится) → сборка корневых `.env`/`.env.watchdog` (bootstrap — единственный писатель, права 600) → health/итоговая сводка PASS/FAIL. Delete-операций НЕТ вообще (D9): teardown — только документированная процедура.
-  - **Док-канон (D10):** `docs/deployment/BUNDLED_SETUP.md` — 14 разделов в порядке маршрута оператора (рамка → требования к хосту с цифрами RAM/диск/CPU и картой портов («Plane ≈ 14 контейнеров») → предусловия → код → секреты → запуск → bootstrap с перечнем manual-step → LLM/Telegram/онбординг ссылками на LITE_SETUP §7–§8/ONBOARDING → smoke (REPLICATION §4) → stateless-проверка → остановка/полный сброс → траблшутинг); каждый шаг = fenced-команда + «Проверка:» PASS/FAIL; REPLICATION.md §1 — строка Type B → ✅ ORCH-103. **Норматив сопровождения (NFR-5):** меняешь шаги Bundled-тиража → обнови BUNDLED_SETUP.md в том же PR.
-  - **Анти-дрейф (D11):** три структурных тест-модуля без docker/сети/LLM — `tests/test_bundle_compose.py` (состав сервисов, пины образов, изоляция томов, key-set-sync, заморозка корневого compose), `tests/test_bundled_setup_doc.py` (14 разделов, FORBIDDEN — импорт из `test_no_host_hardcodes.py`, секрет-эвристика hex≥32/alnum≥40, env-ключи ⊆ канонов, «22 статуса» импортом `plane_sync`, кросс-рефы, CHANGELOG), `tests/test_bootstrap_script.py` (кирпичи, stdlib-only, нет delete-операций/своего списка статусов, unit чистых функций preflight/плана/рендера, exit 0/2/1). `.gitignore` дополнен `deploy/bundled/repos/` (клоны целевого хоста не коммитятся; `.env`/`data/` уже покрыты неякорными паттернами).
-- **ORCH-10a Lite-тираж: инструкция LITE_SETUP + канон watchdog-конфига + анти-дрейф контур** (ORCH-102, `docs`): закрыт Type A эпика ORCH-10 — заказчик разворачивает у себя **только орк+watchdog** и донастраивает окружение (Plane/Gitea/Telegram/LLM) по одной сквозной инструкции «голый хост → работающий конвейер». **Docs+tests** (паттерн ORCH-077/092): `src/**`/`docker-compose.yml`/`Dockerfile`/`scripts/**` — ноль изменений; конвейер (`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД) — байт-в-байт. ADR: `docs/work-items/ORCH-102/06-adr/ADR-001-lite-setup-doc-canon.md`, сквозной `adr-0037-lite-replication-canon.md`.
-  - **Главный продукт (D1/D2):** новый docs-раздел `docs/deployment/` (витрина тиража, читатель — внешний оператор) с golden source `docs/deployment/LITE_SETUP.md` — 13 нормативных разделов в порядке маршрута оператора (рамка → предусловия хоста → перенос кода → конфигурация → Plane → Gitea → LLM → Telegram → запуск → регистрация проекта → smoke → stateless-проверка → траблшутинг ×7); каждый шаг = fenced-команда + явная «Проверка:»/PASS/FAIL; хост-специфика — только плейсхолдеры `<...>`/`$ENV_VAR`; канон не форкается — статусы/env/вебхуки/smoke ссылками на ONBOARDING §1 / REPLICATION §2–§4 / SETUP_WEBHOOKS.
-  - **Канон watchdog-конфига (D5, исход А-4):** новый `.env.watchdog.example` (третий env-example; key-set = блок `WATCHDOG_*` `.env.example`, 19 ключей, токены — пустые плейсхолдеры) закрывает ловушку файла-носителя: sidecar читает ТОЛЬКО `.env.watchdog`, ключ `WATCHDOG_*` в `.env` для него инертен; шапка несёт C-1 (ORCH-100: свой бот, токен орка переиспользовать запрещено) и когерентность порта `WATCHDOG_METRICS_URL` ⇄ `ORCH_DEPLOY_PROD_TARGET_PORT`; `.env.watchdog` добавлен в `.gitignore` (секрет-гигиена, зеркало `.env.staging`).
-  - **Нормативы разделов:** Gitea (D3, исход А-1) — branch protection на `main` НЕ включать (ADR D10 ORCH-009: ломает PR-merge API merge-актора → ложные HOLD; INV-4), pre-receive хуки платформа не вводит, ОДИН глобальный webhook-секрет на все репо; staging-вилка (D6, исход А-5) — базовый Lite-контур БЕЗ staging (нужен только под self-hosting развитие платформы); источник кода (D7, исход А-6) — параметризованный `git clone <ORCHESTRATOR_GIT_URL>`; stateless (AC-3) — пустая БД при первом старте, секреты только свежевыпущенные `gen_secrets.py`, явная проверка чистоты через `GET /queue`.
-  - **Анти-дрейф контур (D8):** новый `tests/test_lite_setup_doc.py` (25 структурных тестов, без сети/LLM/subprocess) — 13 разделов в порядке D2; обязательные кирпичи; key-sync `.env.watchdog.example` ⇄ `.env.example`; каждый упомянутый env-ключ существует в каноне; compose-подмножество (ровно 3 сервиса, staging строго за `profiles: [staging]`, дефолтный `up -d` = ровно орк+watchdog, анти-появление `plane*`/`gitea*`); fenced-скан боевых литералов (импорт `FORBIDDEN` из `test_no_host_hardcodes.py` — один источник истины) + эвристика секретоподобных значений с негативным самочеком; сверка «22 статуса» импортом `plane_sync._PLANE_NAME_TO_KEY`; перекрёстность REPLICATION→LITE_SETUP + CHANGELOG.
-  - **Перекрёстные доки (FR-7):** REPLICATION.md §1 — строка «Type A — Lite» → ✅ ORCH-102 + ссылка; README.md — способность Lite-тиража + `docs/deployment/` в структуре; INFRA.md — `.env.watchdog` в секрет-нормативе + ссылка на deployment-раздел; CLAUDE.md — блок ORCH-102.
-- **Фундамент тиража 10-common: расхардкод хоста + секреты нового хоста + smoke-процедура** (ORCH-101, `feat`): платформа разворачивается на новой инфре **без правки кода** — только env/конфиг (эпик ORCH-10, критический путь обоих типов A Lite / B Bundled; stateless по решению 10.06). Конвейер (`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД) — байт-в-байт не тронут; **каждый дефолт = боевому значению** → пустой/неизменённый `.env` ⇒ поведение 1:1 (kill-switch-природа, отдельный флаг не вводится — NFR-2; enduro не затронут). ADR: `docs/work-items/ORCH-101/06-adr/ADR-001-host-parametrization-secrets-smoke.md`, сквозной `adr-0036-replication-foundation-host-parametrization.md`.
-  - **Расхардкод (D2, FR-1/FR-2):** четыре код-блокера закрыты тремя новыми `Settings`-ключами + реюзом существующих: `agent_home_dir` (`ORCH_AGENT_HOME_DIR`, HOME всех акторских env), `agent_git_name`/`git_email_domain` (`ORCH_AGENT_GIT_NAME`/`ORCH_GIT_EMAIL_DOMAIN`, git-идентичность: агенты — `claude-bot@<домен>` через единый `launcher.agent_git_env()` ×2 места; системные акторы держат платформенные имена `deploy-finalizer`/`post-deploy-monitor` под тем же доменом). `plane_sync.notify_stage_change` строит ссылки Branch/PR из `gitea_public_url`(fallback `gitea_url`)+`gitea_owner` вместо литералов `git.mva154.duckdns.org`/`admin`. `SELF_HOSTING_REPO` — **нормативная платформенная константа** тиража (D3: конфиг-ключ превращал бы опечатку в активацию деплой-машинерии на чужом репо или тихое выключение всех self-гейтов), пин-тест.
-  - **Staging-порт + исполняемый инвариант ORCH-058 (D4):** `_STAGING_PORT` → ключ `staging_port` (`ORCH_STAGING_PORT`, дефолт 8501; то же имя интерполируется в compose `command:` staging — один факт, одно имя); в начале freshness-пути новый **fail-closed guard**: `staging_port == deploy_prod_target_port` → отказ «staging rebuild refused» + Telegram-алерт, **без тихого fallback** — анти-prod-гарантия из подразумеваемой константы стала исполняемой. Имена сервисов/профиля остаются константами.
-  - **Инфра-файлы (D5/D6/D7, FR-3):** `docker-compose.yml` — полная интерполяция `${VAR:-default}` (реестр B: `ORCH_HOST_REPOS_DIR`/`_CLAUDE_DIR`/`_CLAUDE_JSON`/`_SSH_DIR`/`_CLAUDE_CODE_DIR`/`_NODE_BIN`, `ORCH_DOCKER_GID` (group_add «МИНА 1» сохранён ×3), `ORCH_RUN_UID/GID`, реюз `ORCH_DEPLOY_SSH_USER`/`_HOST_REPO_PATH`/`_PROD_TARGET_PORT`); оба app-сервиса получили явный `command:` (прод — `${ORCH_DEPLOY_PROD_TARGET_PORT:-8500}`); группа ORCH-040 (uid/gid/HOME/маунты/useradd) двигается согласованно через `build.args APP_UID/APP_GID/APP_HOME`. `Dockerfile` — `ARG APP_UID/APP_GID/APP_USER/APP_HOME` (useradd параметризован; CMD сознательно остаётся exec-form 8500 — PID-1/сигнальная семантика `init: true` не тронута). `orchestrator-deploy-hook.sh` — `REPO="${REPO:-…}"`; **оба инвокера** (`self_deploy.build_deploy_command`, `image_freshness.rebuild_staging_image`) передают `REPO=` явно из конфига (exit-контракт хука 0/1/2 не тронут).
-  - **Секреты (D8, FR-4):** новый stdlib-only `scripts/gen_secrets.py` — криптослучайные `ORCH_PLANE_WEBHOOK_SECRET`/`ORCH_GITEA_WEBHOOK_SECRET` (`secrets.token_hex(32)`, повторный запуск — другие значения); режим по умолчанию — печать; `--write` **никогда не перезаписывает существующий `.env` молча** (отказ exit=2, перезапись только `--force`); чек-лист внешних токенов (Plane/Gitea/BotFather/watchdog) + нормативное «боевые секреты не копируются». `.env.example` дополнен до полноты ключей старта (+`ORCH_GITEA_OWNER`/`_PUBLIC_URL`, `ORCH_PLANE_BOT_*`, `ORCH_TELEGRAM_*`, `ORCH_PROJECTS_JSON`, блок хост-параметризации).
-  - **Smoke + доки (D9, FR-5/FR-7):** новый runbook `docs/operations/REPLICATION.md` — карта переменных, процедура секретов, пошаговая smoke-процедура с явными PASS/FAIL (compose config → `/health` → `/queue`+`/metrics` → onboarding sandbox → тестовая задача → артефакты `01–04` стадии analysis; расширенно — до `done`), границы 10-common vs Lite vs Bundled, платформенные конвенции; карта env `INFRA.md` дополнена; `.env.staging.example` согласован.
-  - **Анти-регресс (D10, FR-6):** новый структурный сканер `tests/test_no_host_hardcodes.py` — запрещённые литералы (`82.22.50.71`/`/home/slin`/`mva154`/`duckdns`) в исполняемом коде `src/**`+`watchdog/**` ломают CI; комментарии/докстринги исключены через `tokenize`; `config.py` — структурное исключение (канон дефолтов); allowlist пуст; негативная самопроверка (подсаженный литерал ловится). Тесты: `test_host_config_keys.py` (ключи/guard/REPO/D3-пин), `test_infra_parametrization.py` (интерполяция compose = боевым дефолтам, ORCH-040-группа, Dockerfile ARG, полнота `.env.example`), `test_secrets_gen.py`, `test_replication_smoke.py`.
-- **Turnkey-онбординг проектов: kit + операторский CLI + runbook** (ORCH-009, `feat`): способность развернуть **новый** проект одним проходом (домен D5.2 эпика саморазвития) — **вне рантайма и вне конвейера**: `src/**` байт-в-байт (`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД — не тронуты, снапшот-контроль `tests/test_onboarding_invariants.py`), kill-switch не нужен (активация — только явный запуск CLI человеком). Эталон — сам репозиторий orchestrator (каноны ORCH-52b/c/d/e). ADR: `docs/work-items/ORCH-009/06-adr/ADR-001-turnkey-onboarding-kit-and-cli.md` (D1…D11), сквозной `docs/architecture/adr/adr-0035-turnkey-project-onboarding.md`.
-  - **Kit `onboarding/repo-skeleton/` (D1–D3, FR-1/FR-2/FR-3):** параметризуемый каркас нового репо — 6 промптов агентов канона 52d/92 (5 XML-секций в нормативном порядке, «❌ → ✅», `<escalation>` у developer/reviewer/tester, frontmatter-схема 52c с плейсхолдерными датами/моделями, machine-verdict ключи байт-в-байт; язык — канон орка: 5 ru + deployer en c рамкой shared-host-гардрейлов), reviewer-gate «дока не обновлена → `REQUEST_CHANGES`», паспорт `CLAUDE.md`, `AGENTS.md` (карта доков + правила ведения), `CONTRIBUTING.md`, `README`/`CHANGELOG`, скелет `docs/` (`ARCHITECTURE`/`PIPELINE`/`PRODUCT_VISION`/`operations/INFRA.md` с обязательными секциями топологии/env/границ/рисков общего хоста, реестр сквозных ADR), `.env.example`. Плейсхолдеры `{{NAME}}` + stdlib-рендер (без новых pip-зависимостей); словарь — `onboarding/placeholders.json` (биекция словарь↔kit держится тестом). **Канон не форкается (BR-2):** `docs/_templates/` (16) + `docs/_standards/` (3) в kit не хранятся — копируются live из чекаута в момент материализации.
-  - **CLI `scripts/onboard_project.py` (D4–D7, D11, FR-4/FR-5):** режимы `plan` (дефолт, GET-only, ноль мутаций сети/диска) / `apply` (идемпотентный ensure: существующее → `skipped(exists)`, delete-операций нет вовсе) / `verify` (round-trip реестра, резолв всех 22 статусов включая fail-closed `Confirm Deploy`/`STOP`, лейблы, webhook активен, полнота kit в репо, скан неразрешённых плейсхолдеров). Закрытый список read-only импортов из `src` (нулевой дрейф по построению): `projects._parse_projects_json`, `plane_sync._PLANE_NAME_TO_KEY`, `config.settings`. Канонические группы статусов фиксированы ADR D5 (код-критично: `STOP`→`cancelled` ORCH-090; терминальные группы только у Done/Cancelled/STOP — иначе terminal-detection ORCH-068 ложно терминалит). Gitea: репо `auto_init=false` + per-repo webhook (`push`/`pull_request`/`status`, **переиспользует** глобальный `ORCH_GITEA_WEBHOOK_SECRET` — новый сломал бы HMAC существующих, TR-6); initial push — **только** в свежесозданный пустой репо (INV-4 не затрагивается). Реестр: merged-вывод `ORCH_PROJECTS_JSON` через фактический парсер; скрипт `.env` НЕ правит, прод НЕ рестартит, ничего не удаляет (NFR-2); секреты маскируются (NFR-3); Plane CE API-пробел → `manual-step` со ссылкой на runbook (fail-safe, TR-8). Отчёт `created/skipped(exists)/manual-step` + `--json`; exit-коды 0/2/1.
-  - **Runbook `docs/operations/ONBOARDING.md` (FR-6):** полный чеклист (предусловия → Plane → Gitea → kit → регистрация с self-hosting-предупреждением → верификация → откат), каждый ручной шаг с командой проверки; smoke — на **staging-контуре** (8501, изолированная БД) с одноразовым sandbox-проектом (D8), журнал smoke-прогонов. `docs/operations/SETUP_WEBHOOKS.md` обобщён per-repo (без хардкода enduro-trails).
-  - **Анти-дрейф (NFR-4):** структурные канон-тесты kit `tests/test_onboarding_kit.py` (TC-01…08, 19–20), рендер/планы/идемпотентность `tests/test_onboarding_script.py` (TC-02, 09–18, моки, без сети), инварианты `tests/test_onboarding_invariants.py` (TC-21: снапшоты `STAGE_TRANSITIONS`/`QG_CHECKS`, закрытый список импортов CLI, эталонные промпты `.openclaw/agents/` не тронуты).
-  - **fix(tests): герметизация ORCH-41-тестов model/effort от хост-env (разблокировка merge-gate):** re-test merge-gate бежит в прод-окружении орка, где оператор легитимно включил `ORCH_AGENT_FALLBACK_MODEL` и сменил `ORCH_AGENT_MODEL_DEFAULT`/`ORCH_AGENT_EFFORT_*` — `test_resolve_agent_model.py::test_fallback_model_disabled_by_default` и `test_resolve_agent_effort.py::test_flags_present_when_configured` ассертили **заводские** дефолты через env-backed singleton `settings` (в чистом env Gitea CI зелёные → мина на `main`; ветка ORCH-009 `src/` и эти тесты не трогает, детонация от смены прод-env). Фикс: autouse-фикстуры обоих файлов пиняют shipped-дефолты model/fallback-полей (зеркально друг другу), ассерт «G4 выключен по умолчанию» переведён на **класс-дефолт поля** (`type(settings).model_fields["agent_fallback_model"].default == ""` — подлинный инвариант ORCH-074 ADR-001 Решение 3), never-break ассерты `is_valid_model` — байт-в-байт. В чистом CI поведение байт-эквивалентно (фикстуры ставят ровно то, что даёт пустой env). Полный регресс: 1713 passed (было 2 failed / 1711 passed на re-test).
 - **Машинный журнал уроков `lessons`** (ORCH-098, `feat`): шаг 1 («Фундамент», F2) эпика саморазвития — формализует свободнотекстовые «уроки» из `memory/` в **машинную структурированную таблицу отклонений конвейера** `lessons`, фундамент для будущих ретроспективщика (E2), приоритизатора RICE (E3) и Стрим. Чистый **observer-leaf** `src/lessons.py` (never-raise, kill-switch, паттерн `serial_gate`/`coverage_gate`/`metrics`): `record()`/`get()`/`update()`/`snapshot()`. **Инвариант:** журнал — наблюдатель, **не** Quality Gate — `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схемы существующих таблиц байт-в-байт не тронуты; enduro не затронут. ADR: `docs/work-items/ORCH-098/06-adr/ADR-001-lessons-journal.md`, сквозной `docs/architecture/adr/adr-0034-lessons-journal.md`.
   - **Таблица (D1, FR-1):** аддитивная идемпотентная `lessons` (`CREATE TABLE IF NOT EXISTS` в `db.init_db()` + три индекса, restart-safe) — контекст (`work_item_id`/`task_id`/`stage`/`agent`/`repo`), анализ (`root_cause`/`suggestion`), статус (`status`/`related_task`), **колонки атрибуции — сразу и нуллабельно** (`attribution`/`target_repo`/`target_domain`, требование Славы 10.06 / NFR-6, заполняется позже через update; `_ensure_column` форвард-safe на старой таблице) + `source`/`detail`; без `enum`-констрейнтов (слаги forward-compatible). Хелперы `db.record_lesson`/`get_lessons`/`update_lesson`/`lessons_snapshot`/`lessons_recent_dup_exists`.
   - **НЕ скоупится по репо (D2):** журнал observer-only → единственный регулятор — глобальный kill-switch `lessons_enabled` (env `ORCH_LESSONS_ENABLED`, дефолт `True`); **`lessons_repos` НЕ вводится**. Recorder пишет уроки про **любой** репо (включая enduro-trails); репо-разрез — на **выборке** (`get(repo=…)`).

CLAUDE.md

@@ -273,113 +273,6 @@ machine-verdict/схемы существующих таблиц байт-в-б
   `docs/work-items/ORCH-098/06-adr/ADR-001-lessons-journal.md`,
   `docs/architecture/adr/adr-0034-lessons-journal.md`.
 
-## Turnkey-онбординг проектов (ORCH-009)
-Операторская способность развернуть **новый** проект одним проходом — **вне рантайма и вне
-конвейера** (`src/**` байт-в-байт, kill-switch не нужен: активация — только явный запуск CLI
-человеком). Три артефакта: **kit** `onboarding/repo-skeleton/` (параметризуемый каркас нового репо:
-6 промптов канона 52d/92 — 5 ru + deployer en, паспорт `CLAUDE.md`, `AGENTS.md`, `CONTRIBUTING.md`,
-скелет `docs/` с обязательным `operations/INFRA.md`; плейсхолдеры `{{NAME}}`, словарь —
-`onboarding/placeholders.json`; **канон не форкается**: `docs/_templates/`+`docs/_standards/`
-копируются live из чекаута в момент материализации); **CLI** `scripts/onboard_project.py`
-(`plan` — дефолт, GET-only / `apply` — идемпотентный ensure без delete / `verify`): Plane-проект +
-22 статуса с точными именами (read-only импорт `plane_sync._PLANE_NAME_TO_KEY`; группы фиксированы
-ADR: `STOP`→`cancelled`, терминальные группы только Done/Cancelled/STOP) + лейблы
-`autoApprove`/`autoDeploy`/`Bug` → Gitea-репо + per-repo webhook (переиспользует глобальный
-`ORCH_GITEA_WEBHOOK_SECRET`) → материализация kit + initial push **только** в свежесозданный пустой
-репо → merged-вывод `ORCH_PROJECTS_JSON` (round-trip через фактический `_parse_projects_json`);
-скрипт никогда не рестартит прод / не правит `.env` / ничего не удаляет; недоступное в Plane CE
-API → `manual-step` (fail-safe); **runbook** `docs/operations/ONBOARDING.md` (ручные шаги: env +
-управляемый рестарт; smoke — на staging 8501). Анти-дрейф — структурные тесты
-`tests/test_onboarding_{kit,script,invariants}.py`. Детали —
-`docs/work-items/ORCH-009/06-adr/ADR-001-turnkey-onboarding-kit-and-cli.md`, сквозной
-`docs/architecture/adr/adr-0035-turnkey-project-onboarding.md`.
-
-## Тираж платформы: фундамент 10-common (ORCH-101)
-Платформа разворачивается на новой инфре **без правки кода** — только env/конфиг (эпик ORCH-10,
-оба типа A Lite / B Bundled, stateless). Принцип: **дефолт каждого параметра = боевому значению**
-(пустой `.env` ⇒ поведение байт-в-байт; kill-switch-природа, отдельный флаг не вводится).
-`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД — не тронуты.
-- **Расхардкод:** ключи `agent_home_dir`/`agent_git_name`/`git_email_domain` (HOME + git-идентичность
-  акторов: агенты — единый `launcher.agent_git_env()`; системные имена `deploy-finalizer`/
-  `post-deploy-monitor` — платформенные литералы под тем же доменом), `staging_port`; ссылки
-  Plane-комментариев — из `gitea_public_url`/`gitea_owner`. `docker-compose.yml` — интерполяция
-  `${VAR:-default}` (карта `ORCH_HOST_*`/`ORCH_DOCKER_GID`/`ORCH_RUN_UID/GID`; группа ORCH-040
-  uid/gid/HOME/маунты — одни env насквозь, «МИНА 1» сохранена); `Dockerfile` — `ARG APP_*`
-  (CMD exec-form 8500 не тронут); deploy-hook — `"${REPO:-…}"` + явная передача `REPO=` обоими
-  инвокерами. **Платформенные константы (НЕ конфиг):** `SELF_HOSTING_REPO="orchestrator"` (узел
-  «empty CSV → self-hosting only» всех `*_repos`-leaf'ов), имена сервисов/профиля, контейнерный
-  layout. **Инвариант ORCH-058 усилен:** guard fail-closed `staging_port == прод-порт` → отказ
-  freshness-пути ДО любого ssh/build, без тихого fallback.
-- **Секреты нового хоста:** stdlib `scripts/gen_secrets.py` (`secrets.token_hex(32)`; печать по
-  умолчанию; `--write` отказывает при существующем `.env`, перезапись только `--force`); норматив —
-  боевые секреты не копируются. `.env.example` — канон 100% ключей старта.
-- **Smoke тиража:** runbook `docs/operations/REPLICATION.md` (карта env, чек-лист секретов,
-  пошаговый smoke с PASS/FAIL до артефактов `01–04`/`done`, границы 10-common vs Lite vs Bundled).
-  Анти-регресс — `tests/test_no_host_hardcodes.py` (запрещённые литералы в исполняемом коде
-  `src/**`+`watchdog/**`; `tokenize`-исключение комментариев/докстрингов; config-модули — канон
-  дефолтов, вне скана; allowlist пуст). Детали —
-  `docs/work-items/ORCH-101/06-adr/ADR-001-host-parametrization-secrets-smoke.md`, сквозной
-  `docs/architecture/adr/adr-0036-replication-foundation-host-parametrization.md`.
-
-## Lite-тираж: орк+watchdog на инфре заказчика (ORCH-102)
-Закрыт **Type A** эпика ORCH-10 (поверх фундамента 10-common ORCH-101): заказчик разворачивает
-у себя ТОЛЬКО `orchestrator`+`orchestrator-watchdog` и донастраивает окружение
-(Plane/Gitea/Telegram/LLM — его инсталляции) по одной сквозной инструкции. **Docs+tests**
-(паттерн ORCH-077/092): `src/**`/compose/Dockerfile/`scripts/**` не тронуты; конвейер байт-в-байт.
-- **Golden source** — `docs/deployment/LITE_SETUP.md` (новый раздел `docs/deployment/` — витрина
-  тиража, читатель — внешний оператор; vs `docs/operations/` — эксплуатация НАШЕГО прода): 13
-  нормативных разделов в порядке маршрута оператора, каждый шаг = fenced-команда + явная
-  «Проверка:»/PASS/FAIL, хост-специфика только плейсхолдерами; канон не форкается — статусы/env/
-  вебхуки/smoke ссылками на ONBOARDING §1 / REPLICATION §2–§4 / SETUP_WEBHOOKS (явно в доке —
-  только fail-closed имена `Confirm Deploy`/`STOP` и обязательные ключи нового хоста).
-- **Канон watchdog-конфига** — новый `.env.watchdog.example` (key-set = блок `WATCHDOG_*`
-  `.env.example`, держится key-sync тестом): sidecar читает ТОЛЬКО `.env.watchdog`, ключ
-  `WATCHDOG_*` в `.env` для него инертен (ловушка файла-носителя закрыта); C-1 ORCH-100 — свой
-  бот, токен орка не переиспользовать; `.env.watchdog` в `.gitignore`.
-- **Нормативы:** Gitea — branch protection на `main` НЕ включать (ADR D10 ORCH-009 / INV-4),
-  pre-receive не вводится, ОДИН глобальный webhook-секрет; compose НЕ форкается (дефолтный
-  `up -d` = ровно орк+watchdog, staging строго за `profiles: [staging]` — вилка только под
-  self-hosting развитие платформы); stateless — данные/задачи/секреты боевого хоста НЕ
-  переносятся, проверка чистоты через `GET /queue`.
-- **Анти-дрейф** — `tests/test_lite_setup_doc.py` (структурный, без сети/LLM/subprocess):
-  13 разделов в порядке, кирпичи, env-ключи ⊂ `.env.example`, compose-подмножество
-  (анти-появление `plane*`/`gitea*`), fenced-скан `FORBIDDEN` (импорт из
-  `test_no_host_hardcodes.py`) + секрет-эвристика, «22 статуса» сверкой импорта
-  `plane_sync._PLANE_NAME_TO_KEY`, перекрёстность REPLICATION→LITE_SETUP. **Норматив
-  сопровождения (NFR-5):** меняешь шаги тиража → обнови LITE_SETUP.md в том же PR. Детали —
-  `docs/work-items/ORCH-102/06-adr/ADR-001-lite-setup-doc-canon.md`, сквозной
-  `docs/architecture/adr/adr-0037-lite-replication-canon.md`.
-
-## Bundled-тираж: весь стек одним комплектом (ORCH-103)
-Закрыт **Type B** эпика ORCH-10 (поверх 10-common ORCH-101 и канона Lite ORCH-102): заказчик
-**без собственной инфраструктуры** получает весь стек одним комплектом — новый top-level каталог
-**`deploy/bundled/`** (самодостаточный compose: орк + watchdog + Gitea + зеркало upstream Plane CE
-≈14 контейнеров; project name `orchestrator-bundle` = узнаваемый префикс томов/контейнеров;
-`container_name` не пиннится; staging-контура нет вовсе — самразвитие платформы у заказчика =
-маршрут Lite) + **`scripts/bootstrap_bundle.py`** (python stdlib-only, режимы `plan` (дефолт) /
-`apply`/`verify`, step-движок check→ensure, exit 0/2/1), доводящий стек одним прогоном: preflight
-(fail-fast до мутаций) → секреты (webhook — строго `gen_secrets.py`; bundle-креды — stdlib
-`secrets`, без перетирания без `--force-secrets`) → up+готовность → init Gitea (полностью
-автоматом, `gitea admin …`; branch protection НЕ включается — D10 ORCH-009/INV-4) → init Plane
-(честные manual-step c API-верификацией; молчаливый пропуск запрещён) → онбординг sandbox-проекта
-**строго** `onboard_project.py apply+verify` (22 статуса — `plane_sync._PLANE_NAME_TO_KEY`, нулевой
-дрейф канона) → git-доступ агентов HTTP token-remote (ssh-контур не вводится) → сборка корневых
-`.env`/`.env.watchdog` (bootstrap — единственный писатель live-конфигов) → health/итог.
-Сеть — одна bridge, машинный трафик строго сервис-DNS (`http://orchestrator:8500/webhook/*`),
-наружу — только человеческие порты (`BUNDLE_ORCH_PORT`/`BUNDLE_PLANE_PORT`/`BUNDLE_GITEA_HTTP_PORT`);
-мина Gitea закрыта `GITEA__webhook__ALLOWED_HOST_LIST=orchestrator`. Все сторонние образы пиннованы
-неподвижными тегами; teardown — только документированная процедура BUNDLED_SETUP §13 (delete-операций
-в скрипте НЕТ вообще). Рантайм байт-в-байт: `src/**`, корневой compose, `Dockerfile`,
-`STAGE_TRANSITIONS`/`QG_CHECKS`/схема БД — не тронуты; kill-switch не нужен (активация — только
-явный запуск оператором, паттерн ORCH-009/102). Golden source — `docs/deployment/BUNDLED_SETUP.md`
-(14 разделов канона LITE_SETUP; общие шаги — ссылками на LITE_SETUP/ONBOARDING/REPLICATION).
-Анти-дрейф — `tests/test_bundle_compose.py` (состав/пины/key-set-sync/заморозка корневого compose),
-`tests/test_bundled_setup_doc.py` (разделы/FORBIDDEN-импорт/секрет-эвристика/env-ключи/кросс-рефы),
-`tests/test_bootstrap_script.py` (кирпичи/stdlib-only ast-сканом/нет delete-операций/unit чистых
-функций). **Норматив сопровождения (NFR-5):** меняешь шаги Bundled-тиража → обнови BUNDLED_SETUP.md
-в том же PR. Детали — `docs/work-items/ORCH-103/06-adr/ADR-001-bundled-stack-compose-and-bootstrap.md`,
-сквозной `docs/architecture/adr/adr-0038-bundled-replication-canon.md`.
-
 ## Конвенции
 - Conventional Commits (`feat:`, `fix:`, `docs:`, `refactor:`, `test:`)
 - Ветки: `feature/ORCH-NNN-slug`, `fix/ORCH-NNN-slug`

Dockerfile

@@ -35,16 +35,7 @@ RUN set -eux; \
 # "No user exists for uid 1000" (rc=255), breaking the detached self-deploy ssh
 # launch (ORCH-36 Phase B). Create a real user 1000 with a home dir so getpwuid()
 # resolves and ssh can start.
-# ORCH-101 (D5): uid/gid/home/username are build ARGs (defaults = current prod
-# values); compose build.args wires APP_UID/APP_GID/APP_HOME from the SAME env
-# vars as the runtime user: and the mount targets, so the ORCH-040 group
-# (uid/gid/HOME/mounts/useradd) moves coherently. APP_USER is passwd cosmetics
-# (the ENTRY matters for getpwuid/ssh, not the name) — Dockerfile-default only.
-ARG APP_UID=1000
-ARG APP_GID=1000
-ARG APP_USER=slin
-ARG APP_HOME=/home/slin
-RUN groupadd -g ${APP_GID} app && useradd -u ${APP_UID} -g ${APP_GID} -m -d ${APP_HOME} -s /bin/bash ${APP_USER}
+RUN groupadd -g 1000 app && useradd -u 1000 -g 1000 -m -d /home/slin -s /bin/bash slin
 COPY requirements.txt .
 RUN pip install --no-cache-dir -r requirements.txt
 COPY src/ ./src/
@@ -57,9 +48,4 @@ COPY src/ ./src/
 # and bounced the task off `deploy-staging`. We just ensure the mountpoint exists.
 RUN mkdir -p /app/data
 ENV PYTHONPATH=/app
-# ORCH-101 (D5): CMD deliberately stays exec-form with the documented 8500
-# default — an ARG cannot reach a runtime CMD, and a shell-form CMD would break
-# the verified `init: true` + exec-form PID-1/signal semantics (B-2). The prod
-# port is parametrised on the compose layer (`command:` with
-# ${ORCH_DEPLOY_PROD_TARGET_PORT:-8500}), which overrides this CMD.
 CMD ["uvicorn", "src.main:app", "--host", "0.0.0.0", "--port", "8500"]

README.md

@@ -70,8 +70,6 @@ data/
 └── runs/                # Agent output logs ({run_id}.log)
 docs/
 ├── PRODUCT_VISION.md            # Видение продукта
-├── deployment/
-│   └── LITE_SETUP.md            # Lite-тираж: орк+watchdog на инфре заказчика (ORCH-102)
 ├── architecture/
 │   ├── README.md                # Обзор архитектуры, компоненты, API
 │   ├── internals.md             # Схема БД, потоки, resilience-слой
@@ -146,17 +144,6 @@ uvicorn src.main:app --reload --port 8500
 | `ORCH_BUG_FAST_TRACK_ENABLED` | Kill-switch багфикс-трека (ORCH-019): задача с меткой Plane `Bug` пропускает стадию `architecture`; `false` → старт и маршрут 1:1 как до ORCH-019 (нулевая регрессия) | `true` |
 | `ORCH_BUG_FAST_TRACK_LABEL` | Имя метки Plane, активирующей багфикс-трек (ORCH-019) | `Bug` |
 | `ORCH_BUG_FAST_TRACK_REPOS` | CSV область репо для багфикс-трека; **пусто → self-hosting only** (`orchestrator`) — enduro подключается явным CSV (ORCH-019) | `""` |
-| `ORCH_AGENT_HOME_DIR` | ORCH-101: HOME акторских процессов + таргет маунтов `.claude`/`.ssh` + `ARG APP_HOME` (группа ORCH-040) | `/home/slin` |
-| `ORCH_AGENT_GIT_NAME` / `ORCH_GIT_EMAIL_DOMAIN` | ORCH-101: git-идентичность коммитов агентов (`claude-bot@mva154.local` при дефолтах) | `claude-bot` / `mva154.local` |
-| `ORCH_STAGING_PORT` | ORCH-101: порт staging (читают `image_freshness` и compose); guard fail-closed при совпадении с прод-портом (ORCH-058 AC-9) | `8501` |
-| `ORCH_HOST_CLAUDE_DIR` / `_CLAUDE_JSON` / `_SSH_DIR` / `_CLAUDE_CODE_DIR` / `_NODE_BIN` | ORCH-101: host-источники bind-маунтов (compose-интерполяция) | боевые пути mva154 |
-| `ORCH_RUN_UID` / `ORCH_RUN_GID` / `ORCH_DOCKER_GID` | ORCH-101: uid:gid контейнера и gid docker-группы (`group_add`, ORCH-040) | `1000`/`1000`/`999` |
-
-Тираж платформы на новый хост (полная карта, секреты, smoke) — `docs/operations/REPLICATION.md` (ORCH-101).
-**Lite-тираж под ключ (ORCH-102):** разворачивание орк+watchdog на инфраструктуре заказчика
-по одной сквозной инструкции «голый хост → работающий конвейер» (Plane/Gitea/Telegram/LLM
-заказчик ставит сам и подключает по шагам) — `docs/deployment/LITE_SETUP.md`; канон конфига
-sidecar-watchdog — `.env.watchdog.example`; анти-дрейф — `tests/test_lite_setup_doc.py`.
 
 ## Очередь задач (ORCH-1 / F-2b)
 

deploy/bundled/.env.example

@@ -1,61 +0,0 @@
-# deploy/bundled/.env — конфиг bundle-ИНФРЫ (ORCH-103, ADR-001 D2).
-# Канонический example: 100% ключей интерполяции deploy/bundled/docker-compose.yml
-# (key-set-sync держит tests/test_bundle_compose.py) + ключи init-кред, которые
-# заполняет bootstrap. Создание: cp .env.example .env (или это сделает
-# scripts/bootstrap_bundle.py apply); права 600.
-#
-# ⚠️ СЕМАНТИКА ФАЙЛА-НОСИТЕЛЯ (TR-8): этот файл читает ТОЛЬКО compose-интерполяция
-# bundle (авто-чтение .env из project dir deploy/bundled/). Runtime-конфиг самого
-# оркестратора и watchdog — КОРНЕВЫЕ .env / .env.watchdog (каноны Lite 1:1:
-# .env.example / .env.watchdog.example, карта — docs/operations/REPLICATION.md §2).
-# Единственный писатель всех live-файлов — scripts/bootstrap_bundle.py: дублируемые
-# ключи (uid/gid, HOME, пути Claude CLI) когерентны механически, не дисциплиной.
-#
-# DO NOT COMMIT реальный deploy/bundled/.env (покрыт неякорным `.env` в .gitignore).
-# Секреты: НИ ОДНОГО дефолтного пароля — пустые значения ниже генерирует bootstrap
-# (stdlib secrets) и никогда не печатает (NFR-3); повторный запуск НЕ перетирает
-# существующие значения без явного --force-secrets.
-
-# --- Публичная точка инсталляции -------------------------------------------
-# Хост, по которому браузер оператора открывает Plane/Gitea и по которому
-# строятся публичные ссылки (ORCH_GITEA_PUBLIC_URL / ORCH_PLANE_WEB_URL / WEB_URL
-# Plane / ROOT_URL Gitea). HTTPS/домены/reverse-proxy заказчика — вне bundle.
-BUNDLE_PUBLIC_HOST=localhost
-
-# --- Карта публикуемых портов (D4: только человеческие точки) ---------------
-# Конфликт порта на хосте → отказ preflight bootstrap ДО любых мутаций (BR-7).
-BUNDLE_ORCH_PORT=8500
-BUNDLE_PLANE_PORT=8080
-BUNDLE_GITEA_HTTP_PORT=3000
-
-# --- Идентичность контейнера орка (реюз имён ORCH-101: один факт = одно имя) --
-# uid:gid владельца deploy/bundled/repos (инвариант ORCH-040); docker-gid хоста
-# («МИНА 1», узнать: getent group docker). Заполняет bootstrap из id -u/-g/getent.
-ORCH_RUN_UID=1000
-ORCH_RUN_GID=1000
-ORCH_DOCKER_GID=999
-# HOME всех акторов в контейнере (группа ORCH-040 двигается одной переменной).
-ORCH_AGENT_HOME_DIR=/home/orchestrator
-
-# --- LLM-предусловие хоста заказчика (bundle НЕ поставляет Claude CLI) -------
-# Пути дистрибутива claude-code/node и кред CLI на хосте (канон — LITE_SETUP §7).
-ORCH_HOST_CLAUDE_CODE_DIR=/usr/lib/node_modules/@anthropic-ai/claude-code
-ORCH_HOST_NODE_BIN=/usr/bin/node
-ORCH_HOST_CLAUDE_DIR=~/.claude
-ORCH_HOST_CLAUDE_JSON=~/.claude.json
-
-# --- Внутренние креды Plane CE-стека (upstream-имена; значения — bootstrap) --
-POSTGRES_USER=plane
-POSTGRES_PASSWORD=
-POSTGRES_DB=plane
-SECRET_KEY=
-RABBITMQ_DEFAULT_USER=plane
-RABBITMQ_DEFAULT_PASS=
-RABBITMQ_DEFAULT_VHOST=plane
-MINIO_ROOT_USER=plane-minio-admin
-MINIO_ROOT_PASSWORD=
-
-# --- Init-креды Gitea (D6: один пользователь-бот = админ, владелец репо,
-#     носитель API-токена; создаёт bootstrap через `gitea admin user create`) --
-GITEA_ADMIN_USERNAME=orchestrator-bot
-GITEA_ADMIN_PASSWORD=

deploy/bundled/docker-compose.yml

@@ -1,338 +0,0 @@
-# ORCH-103 (Type B Bundled, ADR-001 D1–D4): самодостаточный compose ВСЕГО стека
-# для тиража «под ключ» на хост заказчика: orchestrator + orchestrator-watchdog +
-# Gitea + Plane CE (зеркало официального selfhost-référence makeplane/plane
-# v0.23.1: имена сервисов и env-контракт — upstream, анти-дрейф к их докам; наши
-# отличия от référence: пиннинг неподвижными тегами литералом вместо ${APP_RELEASE}
-# (NFR-6, держится tests/test_bundle_compose.py), убраны replicas/platform/SENTRY,
-# секреты БЕЗ дефолтных значений — их генерирует scripts/bootstrap_bundle.py).
-#
-# Этот файл НЕ исполняется в нашем прод-контуре (корневой docker-compose.yml —
-# байт-в-байт, заморожен анти-дрейфом ORCH-102); активация — только явный запуск
-# оператором на целевом хосте (паттерн ORCH-009, kill-switch не нужен).
-#
-# Конфиг-слои (D2): интерполяции ${VAR} читаются compose'ом из deploy/bundled/.env
-# (авто-чтение из project dir — без --env-file-футгана); канон ключей —
-# deploy/bundled/.env.example (key-set-sync держит тест). Runtime-конфиг орка и
-# watchdog — КОРНЕВЫЕ .env / .env.watchdog (канон Lite 1:1, REPLICATION §2);
-# их единственный писатель — bootstrap_bundle.py.
-#
-# Сеть (D4): одна bridge-сеть проекта; машинный трафик — строго сервис-DNS
-# (Plane→орк http://orchestrator:8500/webhook/plane, Gitea→орк .../webhook/gitea,
-# орк→Plane http://proxy, орк→Gitea http://gitea:3000); network_mode: host НЕ
-# используется (ssh-деплой-контур нашего хоста в bundle структурно спит —
-# ORCH_DEPLOY_SSH_HOST пуст). Наружу публикуются ТОЛЬКО человеческие порты
-# (орк/Plane proxy/Gitea web); postgres/redis/mq/minio не публикуются.
-#
-# Project name = узнаваемый префикс томов/контейнеров orchestrator-bundle_* (D1);
-# container_name сознательно НЕ пиннится ни у кого — bundle и Lite/корневой
-# compose не сталкиваются по именам на одном хосте.
-name: orchestrator-bundle
-
-networks:
-  default:
-    name: orchestrator-bundle
-    driver: bridge
-
-# Env-контракт Plane CE — upstream-имена (référence v0.23.1). Значения секретов
-# (POSTGRES_PASSWORD/SECRET_KEY/RABBITMQ_DEFAULT_PASS/MINIO_ROOT_PASSWORD) живут
-# ТОЛЬКО в deploy/bundled/.env (генерирует bootstrap); дефолтных паролей нет.
-x-plane-env: &plane-env
-  environment:
-    - WEB_URL=http://${BUNDLE_PUBLIC_HOST:-localhost}:${BUNDLE_PLANE_PORT:-8080}
-    - DEBUG=0
-    - CORS_ALLOWED_ORIGINS=http://${BUNDLE_PUBLIC_HOST:-localhost}:${BUNDLE_PLANE_PORT:-8080}
-    - GUNICORN_WORKERS=1
-    # db (upstream-имена; host/port — фиксированные сервис-DNS этого файла)
-    - PGHOST=plane-db
-    - PGDATABASE=${POSTGRES_DB:-plane}
-    - POSTGRES_USER=${POSTGRES_USER:-plane}
-    - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
-    - POSTGRES_DB=${POSTGRES_DB:-plane}
-    - POSTGRES_PORT=5432
-    - PGDATA=/var/lib/postgresql/data
-    - DATABASE_URL=postgresql://${POSTGRES_USER:-plane}:${POSTGRES_PASSWORD}@plane-db:5432/${POSTGRES_DB:-plane}
-    # redis
-    - REDIS_HOST=plane-redis
-    - REDIS_PORT=6379
-    - REDIS_URL=redis://plane-redis:6379/
-    # rabbitmq
-    - RABBITMQ_HOST=plane-mq
-    - RABBITMQ_PORT=5672
-    - RABBITMQ_DEFAULT_USER=${RABBITMQ_DEFAULT_USER:-plane}
-    - RABBITMQ_DEFAULT_PASS=${RABBITMQ_DEFAULT_PASS}
-    - RABBITMQ_DEFAULT_VHOST=${RABBITMQ_DEFAULT_VHOST:-plane}
-    - RABBITMQ_VHOST=${RABBITMQ_DEFAULT_VHOST:-plane}
-    - AMQP_URL=amqp://${RABBITMQ_DEFAULT_USER:-plane}:${RABBITMQ_DEFAULT_PASS}@plane-mq:5672/${RABBITMQ_DEFAULT_VHOST:-plane}
-    # application secret (генерирует bootstrap; дефолта сознательно НЕТ)
-    - SECRET_KEY=${SECRET_KEY}
-    # datastore (minio)
-    - USE_MINIO=1
-    - AWS_REGION=
-    - AWS_ACCESS_KEY_ID=${MINIO_ROOT_USER:-plane-minio-admin}
-    - AWS_SECRET_ACCESS_KEY=${MINIO_ROOT_PASSWORD}
-    - AWS_S3_ENDPOINT_URL=http://plane-minio:9000
-    - AWS_S3_BUCKET_NAME=uploads
-    - MINIO_ROOT_USER=${MINIO_ROOT_USER:-plane-minio-admin}
-    - MINIO_ROOT_PASSWORD=${MINIO_ROOT_PASSWORD}
-    - BUCKET_NAME=uploads
-    - FILE_SIZE_LIMIT=5242880
-    # live server
-    - API_BASE_URL=http://api:8000
-    # proxy
-    - NGINX_PORT=80
-
-services:
-  # ── Платформа: орк + sidecar-watchdog (образы собираются из этого же чекаута;
-  #    корневой Dockerfile / watchdog/Dockerfile — без правок, NFR-1) ──────────
-  orchestrator:
-    build:
-      context: ../..
-      # ORCH-101 (D5): uid/gid/home двигаются ОДНОЙ группой с user: и таргетами
-      # маунтов ниже (инвариант ORCH-040). Дефолты bundle нейтральны (D2).
-      args:
-        APP_UID: ${ORCH_RUN_UID:-1000}
-        APP_GID: ${ORCH_RUN_GID:-1000}
-        APP_HOME: ${ORCH_AGENT_HOME_DIR:-/home/orchestrator}
-    restart: unless-stopped
-    user: "${ORCH_RUN_UID:-1000}:${ORCH_RUN_GID:-1000}"
-    init: true
-    command: ["uvicorn", "src.main:app", "--host", "0.0.0.0", "--port", "8500"]
-    ports:
-      # человеческая точка: операторский smoke `curl /health` (D4)
-      - "${BUNDLE_ORCH_PORT:-8500}:8500"
-    volumes:
-      # данные/репозитории — bind ВНУТРИ project dir (uid-причины ORCH-040;
-      # покрыты .gitignore: неякорный data/ + deploy/bundled/repos/)
-      - ./data:/app/data
-      - ./repos:/repos
-      - /var/run/docker.sock:/var/run/docker.sock
-      # LLM-предусловие хоста заказчика (bundle его НЕ поставляет, BRD §1.3)
-      - ${ORCH_HOST_CLAUDE_CODE_DIR:-/usr/lib/node_modules/@anthropic-ai/claude-code}:/opt/claude-code:ro
-      - ${ORCH_HOST_NODE_BIN:-/usr/bin/node}:/usr/bin/node:ro
-      - ${ORCH_HOST_CLAUDE_DIR:-~/.claude}:${ORCH_AGENT_HOME_DIR:-/home/orchestrator}/.claude
-      - ${ORCH_HOST_CLAUDE_JSON:-~/.claude.json}:${ORCH_AGENT_HOME_DIR:-/home/orchestrator}/.claude.json:ro
-      # ssh-контур в bundle сознательно НЕ вводится (ADR D8): git-доступ агентов
-      # — HTTP token-remote, деплой-хуки нашего хоста структурно спят.
-    # runtime-конфиг орка собирает bootstrap (шаг 8); required:false — первый
-    # `up -d` поднимает стек ДО сборки конфига (AC-1), орк жив без него.
-    env_file:
-      - path: ../../.env
-        required: false
-    environment:
-      - ORCH_REPOS_DIR=/repos
-    group_add:
-      - "${ORCH_DOCKER_GID:-999}"
-
-  orchestrator-watchdog:
-    build:
-      context: ../..
-      dockerfile: watchdog/Dockerfile
-    restart: unless-stopped
-    init: true
-    mem_limit: 128m
-    mem_reservation: 32m
-    volumes:
-      - /var/run/docker.sock:/var/run/docker.sock:ro
-      - ./repos:/repos:ro
-      - ./data:/app/data:ro
-    env_file:
-      - path: ../../.env.watchdog
-        required: false
-    environment:
-      # bundle-сеть ≠ host-network Lite: метрики — по сервис-DNS; имя контейнера
-      # орка детерминировано project name (container_name не пиннится, D1).
-      # environment перекрывает env_file → когерентность механическая (TR-8).
-      - WATCHDOG_METRICS_URL=http://orchestrator:8500/metrics
-      - WATCHDOG_CONTAINERS=orchestrator-bundle-orchestrator-1
-    group_add:
-      - "${ORCH_DOCKER_GID:-999}"
-
-  # ── Gitea (D6): официальный образ, НЕ rootless; init полностью автоматом —
-  #    bootstrap создаёт админа/токен через `gitea admin ...` CLI в контейнере.
-  #    Branch protection на main НЕ настраивается (норматив D10 ORCH-009/INV-4).
-  gitea:
-    image: gitea/gitea:1.22.6
-    restart: unless-stopped
-    ports:
-      - "${BUNDLE_GITEA_HTTP_PORT:-3000}:3000"
-    environment:
-      - GITEA__database__DB_TYPE=sqlite3
-      - GITEA__security__INSTALL_LOCK=true
-      - GITEA__server__DOMAIN=${BUNDLE_PUBLIC_HOST:-localhost}
-      - GITEA__server__ROOT_URL=http://${BUNDLE_PUBLIC_HOST:-localhost}:${BUNDLE_GITEA_HTTP_PORT:-3000}/
-      # ssh-контур не вводится (D8): порт не публикуется, ssh выключен.
-      - GITEA__server__DISABLE_SSH=true
-      - GITEA__service__DISABLE_REGISTRATION=true
-      # МИНА TR-4 (D4): Gitea по умолчанию режет webhook'и в приватные адреса —
-      # без этой строки «задача не появилась» гарантирован.
-      - GITEA__webhook__ALLOWED_HOST_LIST=orchestrator
-    volumes:
-      - gitea-data:/data
-    healthcheck:
-      test: ["CMD", "curl", "-fsS", "http://localhost:3000/api/healthz"]
-      interval: 10s
-      timeout: 5s
-      retries: 12
-
-  # ── Plane CE — зеркало upstream selfhost-référence v0.23.1 (D3) ────────────
-  web:
-    <<: *plane-env
-    image: makeplane/plane-frontend:v0.23.1
-    restart: unless-stopped
-    command: node web/server.js web
-    depends_on:
-      - api
-      - worker
-
-  space:
-    <<: *plane-env
-    image: makeplane/plane-space:v0.23.1
-    restart: unless-stopped
-    command: node space/server.js space
-    depends_on:
-      - api
-      - worker
-      - web
-
-  admin:
-    <<: *plane-env
-    image: makeplane/plane-admin:v0.23.1
-    restart: unless-stopped
-    command: node admin/server.js admin
-    depends_on:
-      - api
-      - web
-
-  live:
-    <<: *plane-env
-    image: makeplane/plane-live:v0.23.1
-    restart: unless-stopped
-    command: node live/dist/server.js live
-    depends_on:
-      - api
-      - web
-
-  api:
-    <<: *plane-env
-    image: makeplane/plane-backend:v0.23.1
-    restart: unless-stopped
-    command: ./bin/docker-entrypoint-api.sh
-    volumes:
-      - logs_api:/code/plane/logs
-    depends_on:
-      - plane-db
-      - plane-redis
-      - plane-mq
-
-  worker:
-    <<: *plane-env
-    image: makeplane/plane-backend:v0.23.1
-    restart: unless-stopped
-    command: ./bin/docker-entrypoint-worker.sh
-    volumes:
-      - logs_worker:/code/plane/logs
-    depends_on:
-      - api
-      - plane-db
-      - plane-redis
-      - plane-mq
-
-  beat-worker:
-    <<: *plane-env
-    image: makeplane/plane-backend:v0.23.1
-    restart: unless-stopped
-    command: ./bin/docker-entrypoint-beat.sh
-    volumes:
-      - logs_beat-worker:/code/plane/logs
-    depends_on:
-      - api
-      - plane-db
-      - plane-redis
-      - plane-mq
-
-  migrator:
-    <<: *plane-env
-    image: makeplane/plane-backend:v0.23.1
-    restart: "no"
-    command: ./bin/docker-entrypoint-migrator.sh
-    volumes:
-      - logs_migrator:/code/plane/logs
-    depends_on:
-      - plane-db
-      - plane-redis
-
-  plane-db:
-    <<: *plane-env
-    image: postgres:15.7-alpine
-    restart: unless-stopped
-    command: postgres -c 'max_connections=1000'
-    volumes:
-      - pgdata:/var/lib/postgresql/data
-    healthcheck:
-      test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]
-      interval: 10s
-      timeout: 5s
-      retries: 12
-
-  plane-redis:
-    <<: *plane-env
-    image: valkey/valkey:7.2.5-alpine
-    restart: unless-stopped
-    volumes:
-      - redisdata:/data
-    healthcheck:
-      test: ["CMD", "valkey-cli", "ping"]
-      interval: 10s
-      timeout: 5s
-      retries: 12
-
-  plane-mq:
-    <<: *plane-env
-    image: rabbitmq:3.13.6-management-alpine
-    restart: always
-    volumes:
-      - rabbitmq_data:/var/lib/rabbitmq
-    healthcheck:
-      test: ["CMD", "rabbitmq-diagnostics", "-q", "ping"]
-      interval: 15s
-      timeout: 10s
-      retries: 12
-
-  plane-minio:
-    <<: *plane-env
-    # upstream-référence держит latest — bundle пиннит неподвижный тег (NFR-6)
-    image: minio/minio:RELEASE.2024-05-28T17-19-04Z
-    restart: unless-stopped
-    command: server /export --console-address ":9090"
-    volumes:
-      - uploads:/export
-    healthcheck:
-      test: ["CMD", "curl", "-fsS", "http://localhost:9000/minio/health/live"]
-      interval: 10s
-      timeout: 5s
-      retries: 12
-
-  proxy:
-    <<: *plane-env
-    image: makeplane/plane-proxy:v0.23.1
-    restart: unless-stopped
-    ports:
-      # человеческая точка: UI Plane в браузере оператора (D4)
-      - "${BUNDLE_PLANE_PORT:-8080}:80"
-    depends_on:
-      - web
-      - api
-      - space
-
-# Состояние Plane/Gitea — именованные тома проекта (префикс orchestrator-bundle_,
-# D1/D2); preflight bootstrap детектирует «грязный хост» по этому префиксу.
-volumes:
-  pgdata:
-  redisdata:
-  uploads:
-  logs_api:
-  logs_worker:
-  logs_beat-worker:
-  logs_migrator:
-  rabbitmq_data:
-  gitea-data:

docker-compose.yml

@@ -1,65 +1,42 @@
-# ORCH-101 (replication foundation): every host-specific value is interpolated
-# as ${VAR:-default}; the defaults equal the current production values, so an
-# empty environment resolves to a byte-for-byte equivalent of the previous file
-# (zero regression, BR-5). Compose reads ${VAR} from the project `.env` /shell —
-# NOT from a service's env_file (so .env.staging does NOT interpolate); the
-# Settings-shared names (ORCH_AGENT_HOME_DIR, ORCH_STAGING_PORT, ...) are read
-# by pydantic from env_file AND by compose from .env — one name per fact (D1).
-# Container-side paths (/app/data, /repos, /opt/claude-code, docker.sock) are a
-# container-layout convention, NOT host values — deliberately not parametrised.
-# See docs/operations/REPLICATION.md for the full variable map.
 services:
   orchestrator:
-    build:
-      context: .
-      # ORCH-101 (D5): uid/gid/home move as ONE coherent group with the runtime
-      # user: and the mount targets below (ORCH-040 invariant).
-      args:
-        APP_UID: ${ORCH_RUN_UID:-1000}
-        APP_GID: ${ORCH_RUN_GID:-1000}
-        APP_HOME: ${ORCH_AGENT_HOME_DIR:-/home/slin}
+    build: .
     container_name: orchestrator
     restart: unless-stopped
     # ORCH-040: бежим под uid:gid хоста (slin=1000:1000), а не root, чтобы
     # артефакты конвейера (worktree + docs) создавались как slin:slin и git на
     # хосте работал без ручного chown. Доступ к docker.sock сохранён через
     # group_add: ["999"] (МИНА 1 — НЕ удалять). См. ADR-001 ORCH-040.
-    user: "${ORCH_RUN_UID:-1000}:${ORCH_RUN_GID:-1000}"
+    user: "1000:1000"
     # init: true injects docker-init (tini) as PID 1 so reparented grandchild
     # processes from the claude/node subprocess tree are reaped (no zombies, B-2).
     init: true
     network_mode: host
-    # ORCH-101 (D5): the prod port is configurable on the compose layer (the
-    # Dockerfile CMD keeps its exec-form 8500 default — ADR-001 D5); the default
-    # resolves byte-for-byte to the previous image CMD. Reuses the existing
-    # ORCH_DEPLOY_PROD_TARGET_PORT (no second truth about the prod port).
-    command: ["uvicorn", "src.main:app", "--host", "0.0.0.0", "--port", "${ORCH_DEPLOY_PROD_TARGET_PORT:-8500}"]
     volumes:
       - ./data:/app/data
-      - ${ORCH_HOST_REPOS_DIR:-/home/slin/repos}:/repos
+      - /home/slin/repos:/repos
       - /var/run/docker.sock:/var/run/docker.sock
-      - ${ORCH_HOST_CLAUDE_CODE_DIR:-/usr/lib/node_modules/@anthropic-ai/claude-code}:/opt/claude-code:ro
-      - ${ORCH_HOST_NODE_BIN:-/usr/bin/node}:/usr/bin/node:ro
-      - ${ORCH_HOST_CLAUDE_DIR:-/home/slin/.claude}:${ORCH_AGENT_HOME_DIR:-/home/slin}/.claude
-      - ${ORCH_HOST_CLAUDE_JSON:-/home/slin/.claude.json}:${ORCH_AGENT_HOME_DIR:-/home/slin}/.claude.json:ro
-      # ORCH-040: target согласован с HOME (launcher: settings.agent_home_dir),
-      # не /root/.ssh — обе стороны двигаются одной переменной ORCH_AGENT_HOME_DIR.
-      - ${ORCH_HOST_SSH_DIR:-/home/slin/.orchestrator-ssh}:${ORCH_AGENT_HOME_DIR:-/home/slin}/.ssh:ro
+      - /usr/lib/node_modules/@anthropic-ai/claude-code:/opt/claude-code:ro
+      - /usr/bin/node:/usr/bin/node:ro
+      - /home/slin/.claude:/home/slin/.claude
+      - /home/slin/.claude.json:/home/slin/.claude.json:ro
+      # ORCH-040: target согласован с HOME=/home/slin (launcher), не /root/.ssh.
+      - /home/slin/.orchestrator-ssh:/home/slin/.ssh:ro
     env_file: .env
     environment:
       - ORCH_REPOS_DIR=/repos
-      - ORCH_HOST_REPOS_DIR=${ORCH_HOST_REPOS_DIR:-/home/slin/repos}
+      - ORCH_HOST_REPOS_DIR=/home/slin/repos
       # legacy enduro deployer (read via os.environ, keep as-is):
-      - DEPLOY_SSH_USER=${ORCH_DEPLOY_SSH_USER:-slin}
+      - DEPLOY_SSH_USER=slin
       - DEPLOY_SSH_HOST=127.0.0.1
-      - DEPLOY_HOOK_SCRIPT=${DEPLOY_HOOK_SCRIPT:-/home/slin/bin/enduro-deploy-hook.sh}
+      - DEPLOY_HOOK_SCRIPT=/home/slin/bin/enduro-deploy-hook.sh
       # ORCH-036 self-deploy (read via pydantic ORCH_ prefix; host-network -> 127.0.0.1, ssh key mounted):
-      - ORCH_DEPLOY_SSH_USER=${ORCH_DEPLOY_SSH_USER:-slin}
+      - ORCH_DEPLOY_SSH_USER=slin
       - ORCH_DEPLOY_SSH_HOST=127.0.0.1
       - ORCH_DEPLOY_HOOK_SCRIPT=scripts/orchestrator-deploy-hook.sh
-      - ORCH_DEPLOY_HOST_REPO_PATH=${ORCH_DEPLOY_HOST_REPO_PATH:-/home/slin/repos/orchestrator}
+      - ORCH_DEPLOY_HOST_REPO_PATH=/home/slin/repos/orchestrator
     group_add:
-      - "${ORCH_DOCKER_GID:-999}"
+      - "999"
 
   # ORCH-100 (FND/F1b): sidecar-watchdog — the monitoring brain in a SEPARATE
   # container (observer separated from observed, ADR-001 D2). Deploying it builds
@@ -83,7 +60,7 @@ services:
     mem_reservation: 32m
     volumes:
       - /var/run/docker.sock:/var/run/docker.sock:ro
-      - ${ORCH_HOST_REPOS_DIR:-/home/slin/repos}:/repos:ro
+      - /home/slin/repos:/repos:ro
       - ./data:/app/data:ro
     # Optional env_file (required: false): a missing .env.watchdog must NOT fail
     # `docker compose up` for the prod orchestrator (self-hosting safety). Absent
@@ -92,7 +69,7 @@ services:
       - path: .env.watchdog
         required: false
     group_add:
-      - "${ORCH_DOCKER_GID:-999}"
+      - "999"
 
   # ORCH-31: staging instance (port 8501, isolated DB).
   # Starts ONLY with: docker compose --profile staging up -d orchestrator-staging
@@ -100,42 +77,35 @@ services:
   orchestrator-staging:
     profiles:
       - staging
-    build:
-      context: .
-      args:
-        APP_UID: ${ORCH_RUN_UID:-1000}
-        APP_GID: ${ORCH_RUN_GID:-1000}
-        APP_HOME: ${ORCH_AGENT_HOME_DIR:-/home/slin}
+    build: .
     container_name: orchestrator-staging
     restart: unless-stopped
     # ORCH-040: тот же uid хоста, что и у prod (см. комментарий выше / ADR-001).
-    user: "${ORCH_RUN_UID:-1000}:${ORCH_RUN_GID:-1000}"
+    user: "1000:1000"
     init: true
     network_mode: host
-    # ORCH-101 (D4): the same ORCH_STAGING_PORT that settings.staging_port reads —
-    # the image_freshness rebuild target and the listening port can never drift.
-    command: ["uvicorn", "src.main:app", "--host", "0.0.0.0", "--port", "${ORCH_STAGING_PORT:-8501}"]
+    command: ["uvicorn", "src.main:app", "--host", "0.0.0.0", "--port", "8501"]
     volumes:
       - ./data/staging:/app/data
-      - ${ORCH_HOST_REPOS_DIR:-/home/slin/repos}:/repos
+      - /home/slin/repos:/repos
       - /var/run/docker.sock:/var/run/docker.sock
-      - ${ORCH_HOST_CLAUDE_CODE_DIR:-/usr/lib/node_modules/@anthropic-ai/claude-code}:/opt/claude-code:ro
-      - ${ORCH_HOST_NODE_BIN:-/usr/bin/node}:/usr/bin/node:ro
-      - ${ORCH_HOST_CLAUDE_DIR:-/home/slin/.claude}:${ORCH_AGENT_HOME_DIR:-/home/slin}/.claude
-      - ${ORCH_HOST_CLAUDE_JSON:-/home/slin/.claude.json}:${ORCH_AGENT_HOME_DIR:-/home/slin}/.claude.json:ro
-      # ORCH-040: target согласован с HOME (settings.agent_home_dir), не /root/.ssh.
-      - ${ORCH_HOST_SSH_DIR:-/home/slin/.orchestrator-ssh}:${ORCH_AGENT_HOME_DIR:-/home/slin}/.ssh:ro
+      - /usr/lib/node_modules/@anthropic-ai/claude-code:/opt/claude-code:ro
+      - /usr/bin/node:/usr/bin/node:ro
+      - /home/slin/.claude:/home/slin/.claude
+      - /home/slin/.claude.json:/home/slin/.claude.json:ro
+      # ORCH-040: target согласован с HOME=/home/slin (launcher), не /root/.ssh.
+      - /home/slin/.orchestrator-ssh:/home/slin/.ssh:ro
     env_file: .env.staging
     environment:
       - ORCH_REPOS_DIR=/repos
-      - ORCH_HOST_REPOS_DIR=${ORCH_HOST_REPOS_DIR:-/home/slin/repos}
-      - DEPLOY_SSH_USER=${ORCH_DEPLOY_SSH_USER:-slin}
+      - ORCH_HOST_REPOS_DIR=/home/slin/repos
+      - DEPLOY_SSH_USER=slin
       - DEPLOY_SSH_HOST=127.0.0.1
-      - DEPLOY_HOOK_SCRIPT=${DEPLOY_HOOK_SCRIPT:-/home/slin/bin/enduro-deploy-hook.sh}
+      - DEPLOY_HOOK_SCRIPT=/home/slin/bin/enduro-deploy-hook.sh
       # Staging DB is isolated via ./data/staging volume mount.
       # Inside the container the path remains /app/data/orchestrator.db (same default),
-      # but on the host it physically lives at ./data/staging/orchestrator.db —
+      # but on the host it physically lives at ./data/staging/orchestrator.db — 
       # completely separate from prod ./data/orchestrator.db.
       - ORCH_DB_PATH=/app/data/orchestrator.db
     group_add:
-      - "${ORCH_DOCKER_GID:-999}"
+      - "999"

docs/architecture/README.md

@@ -122,129 +122,6 @@ F1b (рамка C-1: наблюдатель отделён от наблюдае
 `docs/work-items/ORCH-100/06-adr/ADR-001-sidecar-watchdog.md`,
 `docs/work-items/ORCH-100/07-infra-requirements.md`.
 
-## Turnkey-онбординг проектов (ORCH-009)
-
-Операторская способность развернуть **новый** проект одним проходом: Plane-проект (статусы с
-точными именами + лейблы под машинные контракты) → Gitea-репо (+per-repo webhook) → каркас репо
-(kit) → запись реестра → верификация. Реализуется **вне рантайма и вне конвейера**: `src/**`
-байт-в-байт (`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД — не тронуты),
-kill-switch не нужен (активация — только явный запуск CLI человеком). Эталон — сам репозиторий
-orchestrator (каноны ORCH-52b/c/d/e); enduro-trails эталоном не является.
-
-- **Kit `onboarding/repo-skeleton/`** — параметризуемый каркас нового репо: 6 промптов агентов
-  канона 52d/92 (язык — канон орка: 5 ru + deployer en, ADR-001 D2 ORCH-092), паспорт `CLAUDE.md`,
-  `AGENTS.md` (точка входа агентов: карта доков + правила), `CONTRIBUTING.md`, `README`/`CHANGELOG`,
-  скелет `docs/` с обязательным `operations/INFRA.md`, `.env.example`. Плейсхолдеры `{{NAME}}` +
-  stdlib-рендер (без новых зависимостей); словарь — `onboarding/placeholders.json`. **Канон не
-  форкается (BR-2):** `docs/_templates/` + `docs/_standards/` не хранятся в kit — копируются live
-  из чекаута орка в момент материализации.
-- **CLI `scripts/onboard_project.py`** — `plan` (дефолт, GET-only, ноль мутаций) / `apply`
-  (идемпотентный ensure, без delete-операций) / `verify` (round-trip реестра через фактический
-  `projects._parse_projects_json`, резолв всех статусов включая fail-closed `Confirm Deploy`/`STOP`,
-  лейблы, webhook, полнота kit, скан неразрешённых плейсхолдеров). Имена статусов — read-only
-  импорт `plane_sync._PLANE_NAME_TO_KEY` (22, нулевой дрейф); канонические группы фиксированы ADR
-  (код-критично: `STOP`→`cancelled` ORCH-090; терминальные группы только у Done/Cancelled/STOP —
-  иначе terminal-detection ORCH-068 ложно терминалит). Gitea-webhook переиспользует глобальный
-  `ORCH_GITEA_WEBHOOK_SECRET`; initial push — **только** в свежесозданный пустой репо (INV-4 не
-  затрагивается). Скрипт никогда не рестартит прод / не правит `.env` / ничего не удаляет;
-  регистрация в реестре = операторские env + управляемый рестарт (runbook). Недоступное в
-  Plane CE API → `manual-step` (fail-safe).
-- **Runbook `docs/operations/ONBOARDING.md`** — чеклист всех слоёв, явные ручные шаги, smoke на
-  **staging-контуре** (8501, изолированная БД) с одноразовым sandbox-проектом, откат.
-- **Анти-дрейф:** структурные канон-тесты kit (аналог `tests/test_agent_prompts_canon.py`) +
-  снапшот-тест `STAGE_TRANSITIONS`/`QG_CHECKS`.
-
-Подробнее: [adr-0035](adr/adr-0035-turnkey-project-onboarding.md), детально —
-`docs/work-items/ORCH-009/06-adr/ADR-001-turnkey-onboarding-kit-and-cli.md` (D1…D11),
-`docs/work-items/ORCH-009/07-infra-requirements.md`.
-
-## Тираж платформы: фундамент 10-common (ORCH-101)
-
-Фундамент эпика ORCH-10 (D5.3 «Масштаб»: раздача платформы заказчикам-тестерам, типы A Lite /
-B Bundled, оба stateless). Платформа разворачивается на новой инфре **без правки кода** — только
-env/конфиг; конвейер (`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД) —
-байт-в-байт не тронут. Три слоя:
-
-- **Расхардкод по принципу «дефолт = боевое значение»** (kill-switch-природа: отсутствие новых
-  переменных = текущее поведение 1:1). Новые ключи: `ORCH_AGENT_HOME_DIR` (HOME акторских
-  процессов: launcher ×2 / self-deploy / post-deploy), `ORCH_AGENT_GIT_NAME` +
-  `ORCH_GIT_EMAIL_DOMAIN` (git-идентичности `<actor>@<domain>`; системные имена
-  `deploy-finalizer`/`post-deploy-monitor` — платформенные литералы), `ORCH_STAGING_PORT`.
-  Ссылки в Plane-комментариях — из существующих `gitea_public_url`/`gitea_owner`.
-  `docker-compose.yml` — интерполяция `${VAR:-default}` (карта `ORCH_HOST_*`/`ORCH_DOCKER_GID`/
-  `ORCH_RUN_UID/GID`; группа ORCH-040 uid/gid/HOME/маунты двигается одними env насквозь, «МИНА 1»
-  `group_add` сохранена); `Dockerfile` — `ARG APP_*` (CMD не трогается: exec-form + `init: true`);
-  deploy-hook — `"${REPO:-…}"` + явная передача `REPO=` инвокерами. **Платформенные константы
-  (нормативно, НЕ конфиг):** `SELF_HOSTING_REPO="orchestrator"` (узел «empty CSV → self-hosting
-  only» всех `*_repos`-leaf'ов), имена сервисов/образов/профиля, контейнерный layout.
-  **Инвариант ORCH-058 усилен:** staging-порт конфигурируем только с fail-closed guard'ом
-  (`staging_port == прод-порт` → отказ freshness-пути ДО любого ssh/build, без тихого fallback).
-- **Секреты нового хоста:** stdlib `scripts/gen_secrets.py` (криптослучайные webhook-секреты
-  `secrets.token_hex(32)`; печать по умолчанию; `--write` отказывает при существующем `.env`,
-  перезапись — только явный `--force`) + чек-лист внешних токенов. Норматив: боевые секреты
-  текущего хоста не копируются ни на одном шаге.
-- **Smoke-верификация тиража:** runbook `docs/operations/REPLICATION.md` (deployment golden
-  source: карта env, чек-лист секретов, пошаговый smoke с PASS/FAIL — `/health` → `/queue`+
-  `/metrics` → `onboard_project.py plan/apply/verify` → тестовая задача → артефакты `01–04`;
-  расширенно — до `done`); без нового скрипта — кирпичи уже в репо. Анти-регресс — структурный
-  сканер `tests/test_no_host_hardcodes.py` (запрещённые литералы в исполняемом коде
-  `src/**`+`watchdog/**`; `tokenize`-исключение комментариев/докстрингов; config-модули — канон
-  дефолтов, вне скана; allowlist пуст).
-
-Подробнее: [adr-0036](adr/adr-0036-replication-foundation-host-parametrization.md), детально —
-`docs/work-items/ORCH-101/06-adr/ADR-001-host-parametrization-secrets-smoke.md` (D1…D10),
-`docs/work-items/ORCH-101/07-infra-requirements.md`, `10-tech-risks.md`.
-
-**Type A — Lite (ORCH-102 — design).** Поверх 10-common вводится канон Lite-тиража: новый
-docs-раздел `docs/deployment/` (витрина тиража, читатель — внешний оператор) с golden source
-`docs/deployment/LITE_SETUP.md` — сквозной маршрут «голый хост → работающий конвейер» из 13
-нормативных разделов (предусловия → код → конфиг/секреты → Plane → Gitea → LLM → Telegram →
-запуск → онбординг проекта → smoke → stateless-проверка → траблшутинг), каждый шаг =
-fenced-команда + явная проверка (PASS/FAIL), хост-специфика — только плейсхолдеры. Compose не
-форкается: `docker-compose.yml` сам является Lite-подмножеством (дефолтный `up -d` поднимает
-ровно `orchestrator`+`orchestrator-watchdog`; staging — за профилем, в Lite опционален). Канон
-watchdog-конфига — новый `.env.watchdog.example` (key-set = блоку `WATCHDOG_*` `.env.example`;
-sidecar читает только `.env.watchdog`; C-1 ORCH-100 — отдельный бот). Норматив тиражной
-инсталляции Gitea: branch protection на `main` НЕ включать (D10 ORCH-009, защита merge-актора).
-Анти-дрейф — структурный `tests/test_lite_setup_doc.py`. Рантайм/конвейер — байт-в-байт
-(docs+tests). Подробнее: [adr-0037](adr/adr-0037-lite-replication-canon.md), детально —
-`docs/work-items/ORCH-102/06-adr/ADR-001-lite-setup-doc-canon.md`.
-
-**Type B — Bundled (ORCH-103).** Закрывает эпик ORCH-10: весь стек одним комплектом
-(орк + watchdog + Gitea + Plane CE ≈13–14 контейнеров) для заказчика без собственной
-инфраструктуры. Состав Plane — зеркало официального selfhost-référence v0.23.1
-(upstream-имена сервисов web/space/admin/api/worker/beat-worker/migrator/live +
-plane-db/plane-redis/plane-mq/plane-minio/proxy); Gitea — `gitea/gitea:1.22.6`
-(не rootless, ssh выключен). Новый top-level каталог **`deploy/`** (исполняемые дистрибутивы; дополняет
-`docs/deployment/` — инструкции): `deploy/bundled/docker-compose.yml` — один самодостаточный
-compose с `name: orchestrator-bundle` (узнаваемый префикс томов/контейнеров; `container_name`
-не пиннится — нет коллизий с корневым compose на одном хосте), пиннинг сторонних образов
-неподвижными тегами литералом (не `latest`); корневой compose не форкается (заморожен
-анти-дрейфом ORCH-102); staging-контур орка в bundle отсутствует, репо `orchestrator` не
-регистрируется → self-deploy-машинерия структурно спит (`SELF_HOSTING_REPO`-леафы не матчатся).
-Сеть — одна bridge: машинный трафик строго сервис-DNS (webhooks в обе стороны, API, /metrics),
-наружу — только человеческие порты (Plane 8080 / Gitea 3000 / орк 8500; явный
-`GITEA__webhook__ALLOWED_HOST_LIST=orchestrator` против дефолтного запрета приватных таргетов).
-Конфиг-слои: `deploy/bundled/.env.example` (канон bundle-инфры, key-set-sync тест) → live
-`deploy/bundled/.env` (авто-чтение compose из project dir, без `--env-file`-футгана); runtime
-орка/watchdog — корневые `.env`/`.env.watchdog` ровно по канону Lite (`env_file: required:
-false` до сборки); **единственный писатель live-файлов — bootstrap**.
-`scripts/bootstrap_bundle.py` (python stdlib-only, `plan`-дефолт/`apply`/`verify`, step-движок
-check→ensure, exit 0/2/1): preflight fail-fast до мутаций → секреты (`gen_secrets.py` +
-stdlib-креды стека, в логи не печатаются) → up+ожидание готовности → init Gitea (полностью
-автоматом через CLI; branch protection НЕ включать — D10 ORCH-009) → init Plane CE (честные
-manual-step: инструкция → подтверждение → API-верификация результата) → онбординг
-sandbox-проекта строго `onboard_project.py apply`/`verify` (host-venv, канон ONBOARDING) →
-git-доступ агентов token-remote (`_push_url`-паттерн; ssh-контур не вводится) → сборка env
-орка → health/итог; delete-операций в скрипте нет — teardown только документированной
-процедурой (§13). Golden source — `docs/deployment/BUNDLED_SETUP.md` (14 разделов по канону
-LITE_SETUP, требования к хосту по замеру тестового развёртывания; REPLICATION §1 — отметка
-Type B). Анти-дрейф — `tests/test_bundle_compose.py` / `test_bundled_setup_doc.py` /
-`test_bootstrap_script.py`. Рантайм/конвейер — байт-в-байт; kill-switch не нужен (активация —
-только явный запуск оператора на целевом хосте, паттерн ORCH-009). Подробнее:
-[adr-0038](adr/adr-0038-bundled-replication-canon.md), детально —
-`docs/work-items/ORCH-103/06-adr/ADR-001-bundled-stack-compose-and-bootstrap.md`.
-
 ## Конвейер и Quality Gates
 
 ```

docs/architecture/adr/README.md

@@ -37,17 +37,11 @@ Per-work-item решения живут в `docs/work-items/<id>/06-adr/ADR-NNN-
 | adr-0029 | Гейт покрытия тестами — edge sub-gate + ratchet-базовая линия | proposed | 2026-06-10 | ORCH-027 |
 | adr-0030 | Лёгкий read-only `/metrics` — сырьё о самом орке для sidecar (F1b) | proposed | 2026-06-10 | ORCH-099 |
 | adr-0031 | Нормализация legacy root-owned файлов при миграции uid — детект-leaf + actionable worktree-ошибка | proposed | 2026-06-10 | ORCH-057 |
-| adr-0032 | Багфикс-трек — укороченный маршрут конвейера для багов | proposed | 2026-06-10 | ORCH-019 |
-| adr-0033 | Sidecar-watchdog F1b — мозг мониторинга в отдельном контейнере | proposed | 2026-06-10 | ORCH-100 |
-| adr-0034 | Машинный журнал уроков — таблица `lessons` + observer-leaf | proposed | 2026-06-10 | ORCH-098 |
-| adr-0035 | Turnkey-онбординг проектов — kit + операторский CLI + runbook | proposed | 2026-06-10 | ORCH-009 |
-| adr-0036 | Фундамент тиража платформы — параметризация хоста, секреты, smoke (10-common) | proposed | 2026-06-10 | ORCH-101 |
-| adr-0037 | Канон Lite-тиража — `docs/deployment/LITE_SETUP.md` + `.env.watchdog.example` | proposed | 2026-06-10 | ORCH-102 |
 
 > ⚠️ Историческая коллизия: номер `0007` занят двумя файлами —
 > `adr-0007-reconciler.md` (ORCH-053) и `adr-0007-executable-self-deploy.md`
 > (ORCH-036). Оба accepted; для новых сквозных ADR использовать следующий
-> свободный номер (текущий максимум — `0037`).
+> свободный номер (текущий максимум — `0031`).
 > adr-0014 **amends** adr-0013 (меняет критерий merge-verify на «SHA-в-main»).
 > adr-0016 **amends** adr-0013/0014 (гарантирует открытый код-PR перед merge_pr, ORCH-082).
 > adr-0020 реализует машинный слой к adr-0019 (ORCH-52b→52c).

docs/architecture/adr/adr-0035-turnkey-project-onboarding.md

@@ -1,80 +0,0 @@
----
-work_item: ORCH-009
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# adr-0035: Turnkey-онбординг проектов — kit + операторский CLI + runbook (ORCH-009)
-
-## Статус
-Proposed
-
-## Контекст
-
-Подключение нового проекта к оркестратору — ручная археология по разрозненным докам и памяти;
-каждый пропущенный шаг даёт **тихую деградацию**: без промптов в репо конвейер проекта не работает
-вовсе (launcher резолвит `.openclaw/agents/<role>.md` относительно worktree репо задачи); без
-точных имён статусов Plane ветки `Confirm Deploy` (ORCH-059) / `STOP` (ORCH-090) молча не
-активируются (fail-closed); без лейблов `autoApprove`/`autoDeploy`/`Bug` авто-режимы (ORCH-089)
-и багфикс-трек (ORCH-019) молча выключены (fail-safe). Эталон онбординга — **сам репозиторий
-orchestrator** (каноны ORCH-52b/c/d/e кодифицированы в `docs/_templates/`, `docs/_standards/`,
-`.openclaw/agents/`). Домен D5.2 эпика саморазвития: способность разворачивать новый проект
-одним проходом.
-
-## Решение
-
-Способность реализуется **вне рантайма и вне конвейера** — `src/**` байт-в-байт не меняется
-(`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД/контракт `projects.py`
-нетронуты), kill-switch не нужен (активация — только явный запуск операторского CLI):
-
-1. **Onboarding-kit `onboarding/repo-skeleton/`** — параметризуемый каркас нового репо:
-   6 промптов агентов канона 52d/92 (5 XML-секций, «❌→✅», эмиссия схемы 52c, verdict-ключи
-   байт-в-байт; язык — канон орка: 5 ru + deployer en), паспорт `CLAUDE.md`, `AGENTS.md`
-   (точка входа агентов), `CONTRIBUTING.md`, `README.md`, `CHANGELOG.md`, скелет `docs/` с
-   обязательным `operations/INFRA.md`, `.env.example`. Плейсхолдеры `{{NAME}}` + stdlib-рендер
-   (без новых pip-зависимостей); словарь — `onboarding/placeholders.json` (биекция со
-   вхождениями в kit держится тестами). **Канон не форкается:** `docs/_templates/` +
-   `docs/_standards/` НЕ хранятся в kit — копируются live из чекаута орка в момент материализации.
-2. **Операторский CLI `scripts/onboard_project.py`** — `plan` (дефолт, GET-only, ни одной
-   мутации) / `apply` (идемпотентный ensure, без delete-операций) / `verify`. Шаги: Plane-проект →
-   22 статуса с точными именами из `plane_sync._PLANE_NAME_TO_KEY` (read-only импорт — нулевой
-   дрейф; канонические группы фиксированы: `STOP`→`cancelled`, терминальные группы только у
-   Done/Cancelled/STOP — иначе terminal-detection ORCH-068 ложно терминалит) → лейблы → Gitea-репо
-   (+per-repo webhook `push`/`pull_request`/`status`; HMAC-секрет **переиспользуется** из
-   `ORCH_GITEA_WEBHOOK_SECRET` — приёмник один на все репо) → материализация kit + initial push
-   **только в свежесозданный пустой репо** (INV-4 не затрагивается) → merged-вывод
-   `ORCH_PROJECTS_JSON`, провалидированный фактическим `projects._parse_projects_json`
-   (round-trip). Недоступное в Plane CE API → `manual-step` со ссылкой на runbook (fail-safe).
-   Скрипт **никогда** не рестартит прод, не правит `.env`, не пушит в существующие репо, ничего
-   не удаляет.
-3. **Runbook `docs/operations/ONBOARDING.md`** — полный чеклист: предусловия (токены) → скрипт →
-   операторские шаги (env + управляемый рестарт с self-hosting-предупреждением; UI-only Plane) →
-   верификация (`verify` + smoke) → откат. Smoke-контур — **staging (8501, изолированная БД)** +
-   одноразовый sandbox-проект (`SMK`); протокол — «Журнал smoke-прогонов» в runbook.
-
-Анти-дрейф — структурные тесты kit (аналог `tests/test_agent_prompts_canon.py`) + снапшот-тест
-`STAGE_TRANSITIONS`/`QG_CHECKS` (контроль ненарушения `src`). Branch protection `main` новых репо
-**не включается** (ломала бы PR-merge API merge-актора — ложные HOLD класса ORCH-093).
-
-## Последствия
-
-- **+** Новый проект разворачивается одним проходом проверяемо: все слои (Plane-контракты,
-  webhook, промпты, дока, реестр) закрыты скриптом+runbook; тихие деградации ловит `verify`.
-- **+** Нулевой риск рантайма: изменение docs/templates/scripts/tests-only; регресс
-  enduro/orchestrator невозможен по построению; общая БД не читается и не пишется скриптом.
-- **+** Единый эталон без форка: новые репо получают живой канон момента онбординга;
-  обновления канона в них едут обычными PR с reviewer-gate.
-- **−** Регистрация в реестре остаётся операторской (env + управляемый рестарт — Ф-3,
-  сознательное ограничение NFR-2); разрыв «создано, но не зарегистрировано» виден через `verify`.
-- **−** Закрытый список read-only импортов из `src` (`projects._parse_projects_json`,
-  `plane_sync._PLANE_NAME_TO_KEY`, поля `config.settings`) — связь с приватными именами;
-  поломка при рефакторинге видимая (тесты), расширение списка — только через ADR.
-- **Ограничение:** способность ≠ исполнение: онбординг конкретного заказчика — операторская
-  эксплуатация (вне ORCH-009); тиражирование на новый хост — ORCH-10 (вне объёма).
-
-Детально: `docs/work-items/ORCH-009/06-adr/ADR-001-turnkey-onboarding-kit-and-cli.md`
-(D1…D11 — раскладка, плейсхолдеры, copy-vs-template split, импорт src, группы статусов,
-webhook-секрет, формат реестра, smoke-контур, языковая политика, branch protection, форма CLI).

docs/architecture/adr/adr-0036-replication-foundation-host-parametrization.md

@@ -1,109 +0,0 @@
----
-work_item: ORCH-101
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# adr-0036: Фундамент тиража платформы — параметризация хоста, секреты, smoke (ORCH-101, 10-common)
-
-## Статус
-Proposed
-
-## Контекст
-
-Эпик ORCH-10 (D5.3 «Масштаб») — тираж платформы для заказчиков-тестеров двумя типами (A Lite /
-B Bundled), оба stateless. Платформа была фактически прибита к хосту `mva154`: четыре места в
-`src/**` обходили конфиг (внешний Gitea-URL в `plane_sync`, HOME + git-идентичности акторов в
-`launcher`/`self_deploy`/`post_deploy`), `docker-compose.yml`/`Dockerfile`/deploy-hook несли
-литералы путей/uid/gid/портов; механизма выпуска нового комплекта секретов и процедуры верификации
-развёрнутой копии не существовало. ORCH-101 (10-common) — общий фундамент обоих типов тиража.
-
-Это сквозное решение: оно задаёт **платформенные конвенции тиража** и трогает блоки, помеченные
-маркерами ORCH-036/ORCH-040/ORCH-058 (по `docs/_standards/TRACEABILITY.md` — сводный ADR вместо
-архео-перечисления). Детальный пакет решений (D1…D10) — work-item ADR:
-`docs/work-items/ORCH-101/06-adr/ADR-001-host-parametrization-secrets-smoke.md`.
-
-## Решение
-
-**Принцип: «дефолт = боевое значение».** Каждое хост-специфичное значение читается из конфига
-(`Settings` env `ORCH_*` / compose-интерполяция `${VAR:-default}` / Dockerfile `ARG` /
-shell-default хука) с дефолтом, равным текущему боевому значению. Отсутствие новых переменных =
-байт-в-байт текущее поведение (kill-switch-природа; отдельный функциональный флаг не вводится).
-`src/config.py` и `watchdog/config.py` — единственные легитимные места хост-литералов в коде.
-
-**Новые конфиг-ключи:** `agent_home_dir` (`ORCH_AGENT_HOME_DIR`, `/home/slin`) — HOME всех
-акторских процессов; `agent_git_name` (`claude-bot`) + `git_email_domain` (`mva154.local`) —
-git-идентичности (`<actor>@<domain>`; системные акторы `deploy-finalizer`/`post-deploy-monitor` —
-платформенные литералы); `staging_port` (`ORCH_STAGING_PORT`, `8501`). Ссылки в Plane-комментариях —
-из существующих `gitea_public_url`/`gitea_owner`. Compose-слой — карта `ORCH_HOST_*`/
-`ORCH_DOCKER_GID`/`ORCH_RUN_UID/GID` + реюз `ORCH_DEPLOY_*`; порт прод/стейджинг — явные `command:`
-с `${ORCH_DEPLOY_PROD_TARGET_PORT:-8500}` / `${ORCH_STAGING_PORT:-8501}` (CMD образа не трогается —
-exec-form + `init: true` сохранены).
-
-**Платформенные конвенции тиража (нормативно):**
-1. **`SELF_HOSTING_REPO = "orchestrator"` — константа, не конфиг.** На ней «empty CSV →
-   self-hosting only» всех `*_repos`-leaf'ов; конфигурируемость превращала бы опечатку env в
-   активацию деплой-машинерии на чужом репо или тихое выключение всех self-гейтов. Репо платформы
-   в тираже обязан называться `orchestrator` (REPLICATION.md).
-2. **Имена compose-сервисов/контейнеров/образов, профиль `staging`, `network_mode: host`,
-   контейнерный layout (`/app/data`, `/repos`, `/opt/claude-code`)** — конвенции, не переменные
-   (для образов истина уже в конфиге `deploy_prod_*_image`).
-3. **Staging-порт конфигурируем ТОЛЬКО с fail-closed guard'ом** (усиление инварианта ORCH-058
-   AC-9): freshness-путь отказывает ДО любого ssh/build при
-   `staging_port == deploy_prod_target_port` — без тихого fallback. Explicit-pass таргета хуку
-   (`TARGET_PORT=` и др.) сохранён; добавлена явная передача `REPO=` обоими инвокерами хука
-   (его строка 38 становится `"${REPO:-…}"` — exit-контракт 0/1/2 ORCH-036 не тронут).
-4. **Группа ORCH-040 неделима:** uid/gid/HOME/маунт-таргеты/`useradd` управляются одними env
-   насквозь (`ORCH_RUN_UID/GID`, `ORCH_AGENT_HOME_DIR` → compose `user:`/таргеты/`build.args
-   APP_*`); `group_add` docker-gid («МИНА 1») не удаляется — литерал станет
-   `${ORCH_DOCKER_GID:-999}`.
-
-**Секреты нового хоста:** stdlib-скрипт `scripts/gen_secrets.py` — криптослучайные webhook-секреты
-(`secrets.token_hex(32)`), печать по умолчанию, `--write` отказывает при существующем `.env`
-(перезапись — только явный `--force`); внешние токены (Plane/Gitea/Telegram/watchdog) — по
-чек-листу. Норматив: **боевые секреты текущего хоста не копируются ни на одном шаге**.
-
-**Smoke-верификация тиража:** runbook `docs/operations/REPLICATION.md` (deployment golden source:
-карта env, чек-лист секретов, пошаговый smoke с PASS/FAIL: `compose config` → `/health` →
-`/queue`+`/metrics` → `onboard_project.py plan/apply/verify` → тестовая задача → артефакты `01–04`
-в ветке; расширенно — до `done`; границы 10-common vs Lite vs Bundled). Нового smoke-скрипта нет —
-шаги собраны из существующих кирпичей.
-
-**Анти-регресс (постоянная CI-гарантия):** структурный сканер `tests/test_no_host_hardcodes.py` —
-запрещённые литералы (`82.22.50.71`, `/home/slin`, `mva154`, `duckdns`; список централизован) в
-исполняемом коде `src/**`+`watchdog/**`; `tokenize`-исключение комментариев/докстрингов;
-структурное исключение двух config-модулей (канон дефолтов); allowlist пуст; негативная
-самопроверка.
-
-### Что НЕ меняется
-`STAGE_TRANSITIONS`, состав `QG_CHECKS`, семантика `check_*`, machine-verdict ключи, схема БД —
-байт-в-байт; значения существующих конфиг-дефолтов; INV-4; прод-контейнер в рамках задачи не
-рестартуется (правки compose/Dockerfile инертны до штатного деплоя через staging 8501 →
-`Confirm Deploy`).
-
-## Альтернативы
-- **`ORCH_SELF_HOSTING_REPO` конфигом** — отвергнуто: узел безопасности; опечатка = групповой риск.
-- **Staging-порт константой** — отвергнуто: compose-порт параметризуется (AC-6), константа дала бы
-  рассинхрон слоёв; пара «ключ + guard» строго сильнее.
-- **Smoke-скрипт-обвязка / генератор в `onboard_project.py`** — отвергнуто: лишняя поверхность;
-  разные жизненные циклы (онбординг проекта ≠ provisioning хоста).
-
-## Последствия
-- Платформа разворачивается на чужой инфре env-конфигурацией; критический путь ORCH-10 разблокирован
-  (Lite/Bundled строятся поверх REPLICATION.md).
-- Инвариант ORCH-058 переходит из «подразумеваемого константой» в исполняемый guard; возврат
-  хост-хардкода ломает CI структурно.
-- Цена: ~13 новых env-имён (на текущем хосте настраивать нечего — дефолты боевые) и правило
-  «интерполяция читает `.env`/shell, не `env_file`» (зафиксировано в REPLICATION.md).
-- Откат: не задавать переменные (дефолты = прежнее поведение); полный — revert PR (без миграций).
-
-## Связи
-adr-0005 (ORCH-040 — uid/HOME/«МИНА 1»; группа становится параметризуемой, инвариант сохранён),
-adr-0008 (ORCH-058 — INV-FRESH/AC-9; guard усиливает), adr-0007 (ORCH-036 — exit-контракт хука
-не тронут), adr-0035 (ORCH-009 — onboarding переиспользуется smoke-процедурой; kit не форкается),
-adr-0001 (`is_self_hosting_repo` — конвенция имени закреплена). Детально —
-`docs/work-items/ORCH-101/06-adr/ADR-001-host-parametrization-secrets-smoke.md` (D1…D10),
-`07-infra-requirements.md`, `10-tech-risks.md`.

docs/architecture/adr/adr-0037-lite-replication-canon.md

@@ -1,96 +0,0 @@
----
-work_item: ORCH-102
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# adr-0037: Канон Lite-тиража — `docs/deployment/LITE_SETUP.md` + `.env.watchdog.example` (ORCH-102, 10a)
-
-## Статус
-Proposed
-
-## Контекст
-
-Эпик ORCH-10 (D5 «Масштаб»), тип **A — Lite**: раздача орк+watchdog заказчику-тестеру, окружение
-(Plane/Gitea/LLM/Telegram) он донастраивает сам. Фундамент 10-common (ORCH-101, adr-0036) в
-`main`: технически платформа разворачивается без правки кода, но операционно знания размазаны по
-4 operations-докам, писанным для оператора НАШЕГО хоста, — заказчик не может развернуть Lite без
-доп-вопросов. Решения Владельца 10.06: оба типа тиража stateless; главный продукт ORCH-102 —
-инструкция-golden-source в репо.
-
-Сквозной характер: вводится новый docs-раздел, новый канонический example-файл и нормативы,
-обязательные для всех будущих задач эпика ORCH-10 и для любого агента, меняющего шаги тиража.
-Детальный пакет решений (D1…D9, исходы вопросов ТЗ А-1…А-6) — work-item ADR:
-`docs/work-items/ORCH-102/06-adr/ADR-001-lite-setup-doc-canon.md`.
-
-## Решение
-
-1. **Новый docs-раздел `docs/deployment/` — витрина тиража.** Семантика: `deployment/` — «как
-   развернуть платформу у себя» (читатель — внешний оператор), `operations/` — «как
-   эксплуатировать наш прод». Golden source Lite — **`docs/deployment/LITE_SETUP.md`**:
-   сквозной маршрут «голый хост → работающий конвейер» из 13 нормативных разделов (рамка →
-   предусловия → код → конфиг/секреты → Plane → Gitea → LLM → Telegram → запуск → онбординг →
-   smoke → stateless-проверка → траблшутинг); каждый шаг = fenced-команда + явная проверка
-   (PASS/FAIL); хост-специфика — только плейсхолдеры. Канон не форкается: статусы/env/вебхуки —
-   ссылками на ONBOARDING/REPLICATION/SETUP_WEBHOOKS (`REPLICATION.md` остаётся в
-   `operations/`; перекрёстные ссылки в обе стороны). **Норматив сопровождения:** изменение
-   шагов тиража → обновление LITE_SETUP.md в том же PR (правило агентов №2).
-2. **Compose не форкается.** `docker-compose.yml` сам является Lite-подмножеством (ровно
-   `orchestrator` + `orchestrator-watchdog` + `orchestrator-staging` за `profiles: [staging]`;
-   дефолтный `up -d` поднимает орк+watchdog; сервисов Plane/Gitea нет) — отдельный
-   `docker-compose.lite.yml` не вводится; свойство становится CI-гарантией (структурный тест
-   через `yaml.safe_load`).
-3. **`.env.watchdog.example` — третий канонический env-example** (рядом с `.env.example`/
-   `.env.staging.example`): закрывает ловушку файла-носителя (sidecar читает ТОЛЬКО
-   `.env.watchdog`; ключ `WATCHDOG_*` в `.env` для него инертен). Key-set = ровно блок
-   `WATCHDOG_*` из `.env.example` (равенство множеств держит тест); токены — плейсхолдеры;
-   шапка несёт C-1 ORCH-100 (отдельный watchdog-бот, токен орка переиспользовать запрещено)
-   и когерентность `WATCHDOG_METRICS_URL` ⇄ `ORCH_DEPLOY_PROD_TARGET_PORT`.
-4. **Норматив тиражной инсталляции Gitea: branch protection на `main` НЕ включать; pre-receive
-   хуки не вводятся** (подтверждение ORCH-009 ADR-001 D10 для чужих инсталляций:
-   required-approvals/status-checks ломают PR-merge API merge-актора → ложные HOLD; защита
-   `main` — конвенция + скоуп токенов + INV-4).
-5. **Staging-контур в Lite опционален:** базовый контур заказчика = prod-оркестратор + watchdog;
-   песочница 8501 нужна только при self-hosting развитии платформы у заказчика (регистрация
-   проекта `orchestrator`); guard ORCH-058 (staging-порт ≠ прод-порт) действует.
-6. **Анти-дрейф — постоянная CI-гарантия:** `tests/test_lite_setup_doc.py` (структурный, без
-   сети/LLM): разделы/кирпичи дока, env-ключи дока ⊂ `.env.example`, key-sync watchdog-example,
-   compose-подмножество, stateless-норматив + отсутствие секретов/боевых литералов в
-   fenced-блоках (реюз центрального `FORBIDDEN` из `tests/test_no_host_hardcodes.py` импортом),
-   перекрёстность REPLICATION→LITE_SETUP + CHANGELOG.
-
-### Что НЕ меняется
-`src/**`, `docker-compose.yml`, `Dockerfile`, `scripts/**`; `STAGE_TRANSITIONS`, состав
-`QG_CHECKS`, семантика `check_*`, machine-verdict ключи, схема БД — байт-в-байт. Новый QG не
-регистрируется (структурные тесты попадают в существующие гейты). Прод-контейнер в рамках
-задачи не рестартуется (выкат — штатно: staging 8501 → `Confirm Deploy`).
-
-## Альтернативы
-- **Инструкция в `docs/operations/`** — отвергнуто: другой целевой читатель; путь зафиксирован
-  Владельцем (D-4).
-- **`docker-compose.lite.yml`** — отвергнуто: вторая правда о сервисах = дрейф-поверхность.
-- **Pre-receive/branch protection как «защита `main`»** — отвергнуто: класс инцидента ORCH-063
-  (ложные HOLD merge-актора); пересмотр — только отдельным ADR.
-- **Без example-файла watchdog (шаг прозой)** — отвергнуто: двусмысленность файла-носителя
-  остаётся; example + key-sync тест надёжнее.
-
-## Последствия
-- Type A эпика ORCH-10 закрыт продуктом-инструкцией; Type B (Bundled) строится поверх
-  (переиспользует разделы Lite). Полнота инструкции и compose-подмножество защищены CI.
-- Цена: новый golden source требует сопровождения (норматив «в том же PR» + структурный тест
-  рвёт CI при дрейфе); осознанный дубль ключей `WATCHDOG_*` в двух example-файлах — под
-  key-sync тестом.
-- Откат: удалить `docs/deployment/`, тест и `.env.watchdog.example`, вернуть строку
-  REPLICATION.md §1 — состояние 1:1 (docs+tests, без миграций).
-
-## Связи
-adr-0036 (ORCH-101 — фундамент 10-common; этот ADR строит слой Lite поверх), adr-0035
-(ORCH-009 — onboarding-CLI/kit переиспользуются маршрутом §5/§6/§10; D10 подтверждён п.4),
-adr-0033 (ORCH-100 — sidecar-watchdog; C-1 независимый Telegram-канал закреплён в example),
-adr-0008 (ORCH-058 — staging-порт guard, вилка staging п.5), adr-0027/INV-4 (merge-актор —
-основание запрета branch protection). Детально —
-`docs/work-items/ORCH-102/06-adr/ADR-001-lite-setup-doc-canon.md`,
-`docs/work-items/ORCH-102/10-tech-risks.md`.

docs/architecture/adr/adr-0038-bundled-replication-canon.md

@@ -1,114 +0,0 @@
----
-work_item: ORCH-103
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-11
-model_used: claude-opus-4-8
----
-
-# adr-0038: Канон Bundled-тиража — `deploy/bundled/` + bootstrap + `BUNDLED_SETUP.md` (ORCH-103, 10b)
-
-## Статус
-Proposed
-
-## Контекст
-
-Эпик ORCH-10 (D5 «Масштаб»), тип **B — Bundled**: заказчик без собственной инфраструктуры
-получает **весь стек одним комплектом** (орк + watchdog + Gitea + Plane CE ≈13–14 контейнеров) и
-bootstrap, доводящий его до рабочего конвейера одним запуском. Фундамент готов: 10-common
-(ORCH-101, adr-0036 — хост-параметризация/секреты/smoke) и Lite (ORCH-102, adr-0037 — док-канон
-`docs/deployment/`). Корневой `docker-compose.yml` заморожен анти-дрейфом ORCH-102 (ровно 3
-сервиса, запрет подстрок `plane`/`gitea`) → комплект обязан жить отдельным файлом.
-
-Сквозной характер: вводится новый top-level каталог `deploy/` (дистрибутивы развёртывания),
-новый канонический env-example и нормативы, обязательные для будущих задач эпика ORCH-10 и
-любого агента, меняющего шаги тиража. Детальный пакет решений (D1…D11, исходы OQ-1…OQ-7 ТЗ) —
-work-item ADR: `docs/work-items/ORCH-103/06-adr/ADR-001-bundled-stack-compose-and-bootstrap.md`.
-
-## Решение
-
-1. **Новый top-level каталог `deploy/` — исполняемые дистрибутивы развёртывания** (дополняет
-   `docs/deployment/` — инструкции). Bundled-комплект: **`deploy/bundled/docker-compose.yml`** —
-   один самодостаточный compose всего стека с top-level `name: orchestrator-bundle` (project
-   name = узнаваемый префикс томов/контейнеров; `container_name` не пиннится — нет коллизий с
-   корневым compose на одном хосте). Staging-контур орка в bundle **отсутствует вовсе**; репо
-   `orchestrator` в bundle-инсталляции не регистрируется → self-deploy-машинерия структурно спит
-   (`SELF_HOSTING_REPO`-леафы не матчатся).
-2. **Конфиг-слои:** `deploy/bundled/.env.example` — канон bundle-инфры (committed, плейсхолдеры;
-   key-set-sync тест: каждая `${VAR}`-интерполяция bundle-compose имеет ключ в каноне) → live
-   `deploy/bundled/.env` (авто-чтение compose из project dir — без `--env-file`-футгана; покрыт
-   неякорным `.env` в `.gitignore`); runtime орка/watchdog — **корневые `.env`/`.env.watchdog`
-   ровно по канону Lite** (REPLICATION §2 применим 1:1), в bundle-compose — `env_file:
-   required: false` (первый `up` жив до сборки конфига). **Bootstrap — единственный писатель**
-   всех трёх live-файлов (когерентность дублируемых ключей — механическая). Один факт = одно имя
-   (ORCH-101 D1): существующие факты — существующие `ORCH_*`-имена; bundle-only — `BUNDLE_*`;
-   внутренние креды Plane — upstream-имена.
-3. **Состав/пиннинг:** Plane CE — зеркало официального selfhost-référence (upstream-имена
-   сервисов/env); Gitea — `gitea/gitea` (не rootless). Пиннинг — **точный неподвижный тег
-   литералом** (не `latest`, не интерполяция; digest не требуется); точные теги фиксирует
-   developer по проверенному стенду; форму держит структурный тест.
-4. **Сеть:** одна именованная bridge-сеть; машинный трафик — строго сервис-DNS
-   (`http://orchestrator:8500/webhook/*`, `http://gitea:3000`, plane-proxy); `network_mode: host`
-   в bundle не используется (ssh-деплой-пути неактивны: `ORCH_DEPLOY_SSH_HOST` пуст). Наружу —
-   только человеческие порты (Plane proxy 8080 / Gitea 3000 / орк 8500; конфигурируемы);
-   БД/брокер/minio не публикуются. Публичные URL — от `BUNDLE_PUBLIC_HOST` (split internal/public
-   уже в конфиге орка). Мина Gitea закрывается явно: `GITEA__webhook__ALLOWED_HOST_LIST=orchestrator`.
-5. **Bootstrap `scripts/bootstrap_bundle.py`:** python stdlib-only, без импортов из `src/**`;
-   режимы `plan` (дефолт, ноль мутаций) / `apply` / `verify`; step-движок check→ensure
-   (идемпотентность, resume = повторный запуск); exit `0/2/1`. Preflight fail-fast до мутаций
-   (docker/порты/чистота томов по префиксу/RAM/диск; Claude CLI — warning). **Кирпичи не
-   дублируются:** секреты — субпроцесс `gen_secrets.py`; статусы/лейблы/репо/вебхуки — строго
-   `onboard_project.py apply`+`verify` (host-venv, канон ONBOARDING). Init Gitea — полностью
-   автоматом (CLI в контейнере; branch protection НЕ настраивается — D10 ORCH-009/adr-0037 п.4);
-   init Plane CE — честные **manual-step чекпоинты** (инструкция → подтверждение →
-   API-верификация; прогрессивная автоматизация разрешена без смены контракта). Git-доступ
-   агентов — HTTP token-remote (паттерн `_push_url`); ssh-контур не вводится. Секреты в
-   логи не печатаются; delete-операций в скрипте нет вообще — teardown только документированной
-   процедурой (`BUNDLED_SETUP` §13).
-6. **Док-канон:** `docs/deployment/BUNDLED_SETUP.md` — 14 нормативных разделов по форме
-   LITE_SETUP (fenced-команда + «Проверка:» PASS/FAIL, плейсхолдеры, общие шаги ссылками на
-   LITE_SETUP/ONBOARDING/REPLICATION — канон не форкается), включая «Требования к хосту» с
-   цифрами **по замеру** тестового развёртывания. REPLICATION §1: Type B → ✅ ORCH-103.
-   **Норматив сопровождения:** изменил шаги Bundled-тиража → обнови BUNDLED_SETUP.md в том же PR.
-7. **Анти-дрейф — постоянная CI-гарантия:** `tests/test_bundle_compose.py` /
-   `test_bundled_setup_doc.py` / `test_bootstrap_script.py` (структурные, без docker/сети/LLM:
-   состав сервисов, заморозка корневого compose, пины, key-set-sync, разделы дока, FORBIDDEN —
-   импортом из `test_no_host_hardcodes.py`, секрет-эвристика, ссылки на кирпичи, отсутствие
-   delete-операций, unit чистых функций preflight/плана, exit-контракт).
-
-### Что НЕ меняется
-`src/**`, корневой `docker-compose.yml`, `Dockerfile`, `.gitea/workflows/**`, `onboarding/**`,
-промпты `.openclaw/agents/**`; `STAGE_TRANSITIONS`, состав `QG_CHECKS`, семантика `check_*`,
-machine-verdict ключи, схема БД — байт-в-байт. Kill-switch не вводится (активация — только явный
-запуск оператора на целевом хосте, паттерн ORCH-009). Прод-контейнер в рамках задачи не
-рестартуется; наши данные/секреты не переносятся (stateless, решение Владельца 10.06).
-
-## Альтернативы
-- **Расширение корневого compose (профиль `bundled`)** — отвергнуто: заморожен анти-дрейфом
-  ORCH-102/нормативом «compose не форкается»; смешение дистрибутива с боевым контуром.
-- **Include-композиция / live-env через `--env-file`** — отвергнуто: лишние степени свободы
-  запуска, молчаливые дефолты при забытом флаге.
-- **Орк в bundle на host-network + `host-gateway`** — отвергнуто: хост-сеть нужна была
-  ssh-деплой-контуру нашего хоста, который в bundle спит; bridge даёт чистые двунаправленные
-  сервис-DNS-URL.
-- **Digest-пиннинг / rootless-Gitea / ssh-доступ агентов / bash-bootstrap / reset-режим
-  скрипта** — отвергнуты (см. work-item ADR-001, «Альтернативы»).
-
-## Последствия
-- Эпик ORCH-10 закрыт по обоим типам: A (Lite, инструкция) + B (Bundled, комплект); заказчик
-  без инфраструктуры разворачивает конвейер «под ключ».
-- Цена: пиннованные версии Plane/Gitea стареют (апгрейд — отдельные задачи); manual-step Plane CE
-  размывают «одну команду» — неустранимо честно (нет API), митигировано контрактом чекпоинта;
-  двойной `.env`-слой — под единственным писателем-bootstrap и key-sync тестом.
-- Откат: удалить `deploy/`, bootstrap, BUNDLED_SETUP.md, три тест-модуля, строку REPLICATION §1 —
-  состояние 1:1 (docs+scripts+tests, без миграций).
-
-## Связи
-adr-0036 (ORCH-101 — фундамент 10-common: параметризация, gen_secrets, REPLICATION/smoke),
-adr-0037 (ORCH-102 — док-канон `docs/deployment/`, compose-подмножество, запрет branch
-protection), adr-0035 (ORCH-009 — onboarding-CLI: 22 статуса, manual-step паттерн, `_push_url`,
-D10), adr-0027/INV-4 (merge-актор — основание норматива Gitea), adr-0001
-(`SELF_HOSTING_REPO`-конвенция — почему self-гейты в bundle спят). Детально —
-`docs/work-items/ORCH-103/06-adr/ADR-001-bundled-stack-compose-and-bootstrap.md`,
-`07-infra-requirements.md`, `10-tech-risks.md`.

docs/deployment/BUNDLED_SETUP.md

@@ -1,436 +0,0 @@
-# BUNDLED_SETUP — Bundled-тираж: весь стек одним комплектом (ORCH-103)
-
-> **Golden source Bundled-тиража (Type B эпика ORCH-10).** Маршрут «чистый хост →
-> работающий конвейер» для заказчика **без собственной инфраструктуры**: один
-> compose-комплект (`deploy/bundled/docker-compose.yml`) поднимает оркестратор +
-> watchdog + Gitea + Plane CE, один запуск `scripts/bootstrap_bundle.py apply`
-> доводит стек до рабочего состояния. Каждый шаг — исполняемая команда + явная
-> проверка результата (**Проверка:** / PASS / FAIL). Хост-специфика — только
-> плейсхолдеры `<...>` и `$ENV_VAR`. Тираж **stateless**: данные/задачи/секреты
-> боевого (исходного) хоста **НЕ переносятся** ни на одном шаге (§12).
-> Границы слоёв тиража (10-common vs Lite vs Bundled) — `docs/operations/REPLICATION.md` §1;
-> канон Lite (своя инфраструктура Plane/Gitea) — `docs/deployment/LITE_SETUP.md`.
-
----
-
-## 1. Рамка Bundled
-
-**Что входит в комплект** (compose-проект `orchestrator-bundle`, одна bridge-сеть):
-- `orchestrator` (конвейер, образ собирается из этого чекаута) и
-  `orchestrator-watchdog` (независимый sidecar-мониторинг);
-- **Gitea** (git-хостинг, пиннованный официальный образ);
-- **Plane CE — ≈ 14 контейнеров** (зеркало официального selfhost-комплекта:
-  web/space/admin/api/worker/beat-worker/migrator/live + postgres/redis/
-  rabbitmq/minio/proxy) — это **ресурсоёмко**, см. §2.
-
-**Что НЕ входит** (внешние предусловия заказчика):
-- **Claude CLI / LLM-доступ** — дистрибутив claude-code, node и аутентификация
-  живут на хосте и пробрасываются маунтами (§8); без них стек поднимется, но
-  конвейер не поедет;
-- **Telegram-боты** — опциональны (§9): пусто = деградация только нотификаций;
-- **HTTPS/домены/reverse-proxy** — вне bundle: наружу публикуются три http-порта
-  (§2), терминирование TLS — средствами заказчика.
-
-**Bundled vs Lite:** Lite (`LITE_SETUP.md`) подключает оркестратор к **вашим**
-Plane/Gitea; Bundled везёт их **с собой** на чистых томах. Staging-контур орка в
-bundle отсутствует вовсе: заказчик Type B эксплуатирует платформу для своих
-проектов, а не развивает её self-hosting'ом (нужен self-hosting — маршрут Lite,
-`LITE_SETUP.md` §9.3). Репо `orchestrator` в bundle-инсталляции **не
-регистрируется** как проект.
-
-**Осознанный компромисс (TR-7):** git-доступ агентов — HTTP token-remote
-(токен бот-юзера в конфиге локальных чекаутов, права 600); ssh-контур
-сознательно не вводится; порты БД/брокера/minio наружу не публикуются.
-
----
-
-## 2. Требования к хосту
-
-Linux x86_64, один хост. Минимумы проверяет preflight bootstrap **до любых
-мутаций** (пороги — константы `scripts/bootstrap_bundle.py`, ниже — те же цифры;
-подтверждаются замером приёмочного развёртывания):
-
-| Ресурс | Минимум | Почему |
-|--------|---------|--------|
-| RAM | **8 GB** | Plane CE — ≈ 14 контейнеров (миграции и брокер прожорливы) |
-| Диск | **40 GB** свободно | образы стека + тома postgres/minio/gitea + данные орка |
-| CPU | **4 vCPU** (рекомендация) | меньше — стек поднимется, но будет медленным |
-
-**Карта публикуемых портов** (дефолты; конфигурируемы в
-`deploy/bundled/.env`, ключи `BUNDLE_*`):
-
-| Порт | Ключ | Сервис |
-|------|------|--------|
-| 8500 | `BUNDLE_ORCH_PORT` | API оркестратора (`/health`, `/queue`, `/metrics`, вебхуки) |
-| 8080 | `BUNDLE_PLANE_PORT` | Plane UI (proxy) |
-| 3000 | `BUNDLE_GITEA_HTTP_PORT` | Gitea web/API |
-
-Postgres/redis/rabbitmq/minio наружу **не публикуются** (машинный трафик —
-внутрисетевой сервис-DNS).
-
-```bash
-free -g                                   # RAM ≥ 8 GB
-df -h .                                   # свободно ≥ 40 GB
-nproc                                     # ≥ 4
-ss -ltn | grep -E ':(8500|8080|3000)\b' || echo "ports free"
-```
-
-**Проверка:** ресурсы не ниже минимумов и `ports free` — PASS. Порт занят →
-смените соответствующий `BUNDLE_*`-ключ в §5 (или освободите порт) — иначе
-preflight откажет (FAIL до мутаций, это штатно).
-
----
-
-## 3. Предусловия
-
-Софт хоста: Docker Engine + Compose v2, git, python3 (+venv), sudo у оператора.
-
-```bash
-uname -sm                      # Linux x86_64
-docker --version && docker compose version
-git --version && python3 --version
-python3 -m venv --help >/dev/null && echo "venv: ok"
-getent group docker            # третье поле — gid, понадобится в §5 (ORCH_DOCKER_GID)
-id -u && id -g                 # uid/gid оператора (ORCH_RUN_UID / ORCH_RUN_GID)
-```
-
-**Проверка:** все команды отвечают без ошибок, gid группы docker известен —
-PASS; что-то отсутствует — FAIL (доставьте пакет средствами дистрибутива).
-
----
-
-## 4. Получение кода
-
-Переносится **только код** — чекаут репо `orchestrator` (норматив §12).
-
-```bash
-git clone <ORCHESTRATOR_GIT_URL> <путь-чекаута>
-cd <путь-чекаута>
-ls deploy/bundled/docker-compose.yml deploy/bundled/.env.example \
-   scripts/bootstrap_bundle.py scripts/gen_secrets.py scripts/onboard_project.py
-```
-
-**Проверка:** все пять файлов на месте — PASS. Канал дистрибуции
-(`<ORCHESTRATOR_GIT_URL>`) согласуйте с поставщиком платформы (как в
-`LITE_SETUP.md` §3).
-
----
-
-## 5. Секреты
-
-Все секреты инсталляции выпускаются **заново на месте** (§12): webhook-секреты —
-`scripts/gen_secrets.py`, внутренние креды Plane/Gitea-стека — генерирует
-bootstrap (в репо — только пустые плейсхолдеры, ни одного дефолтного пароля).
-
-**5.1. Конфиг bundle-инфры.**
-
-```bash
-cd <путь-чекаута>
-cp deploy/bundled/.env.example deploy/bundled/.env
-chmod 600 deploy/bundled/.env
-# заполнить НЕсекретные ключи: BUNDLE_PUBLIC_HOST (IP/имя хоста для браузера),
-# карту портов BUNDLE_* (§2), ORCH_RUN_UID/ORCH_RUN_GID (из §3),
-# ORCH_DOCKER_GID (getent group docker, §3), пути Claude CLI (§8).
-```
-
-**Проверка:**
-
-```bash
-docker compose -f deploy/bundled/docker-compose.yml config --quiet && echo "config: PASS"
-```
-
-`config: PASS` — интерполяция согласована; ошибка — FAIL (опечатка в
-`deploy/bundled/.env`).
-
-**5.2. Секрет-значения** (пустые ключи `deploy/bundled/.env` и корневого `.env`)
-заполнит `bootstrap_bundle.py apply` (§7): webhook-секреты — субпроцессом
-`gen_secrets.py`, креды postgres/rabbitmq/minio/`SECRET_KEY` Plane и пароль
-админ-бота Gitea — stdlib-генератором. Значения **не печатаются** (только имена
-ключей); повторный запуск **не перетирает** существующие секреты (явная
-регенерация — флаг `--force-secrets`, допустим только ДО первого запуска стека).
-
-```bash
-grep -cE '^(POSTGRES_PASSWORD|SECRET_KEY|RABBITMQ_DEFAULT_PASS|MINIO_ROOT_PASSWORD|GITEA_ADMIN_PASSWORD)=$' \
-  deploy/bundled/.env
-```
-
-**Проверка:** до §7 счётчик `5` (пустые плейсхолдеры) — PASS; после §7 — `0`.
-
----
-
-## 6. Запуск bundle-compose
-
-Одна команда поднимает весь стек (≈ 16 контейнеров; первый запуск тянет образы
-и гоняет миграции Plane — это минуты, не секунды).
-
-```bash
-docker compose -f deploy/bundled/docker-compose.yml up -d
-docker compose -f deploy/bundled/docker-compose.yml ps
-```
-
-**Проверка:** все сервисы в состоянии `Up`/`Up (healthy)`; `migrator` —
-`Exited (0)` (одноразовая миграция) — PASS. Контейнер в рестарт-цикле — FAIL
-(§14). Шаг идемпотентен; можно пропустить — `bootstrap_bundle.py apply` выполнит
-`up -d` сам (§7).
-
----
-
-## 7. Bootstrap
-
-Доводка «одним запуском»: preflight → секреты → up/готовность → init Gitea
-(полностью автоматом: админ-бот + API-токен) → init Plane → онбординг
-sandbox-проекта **строго** кирпичом `onboard_project.py` (22 канонических
-статуса, включая fail-closed **`Confirm Deploy`** и **`STOP`**, лейблы,
-репо+webhook — golden source `docs/operations/ONBOARDING.md` §1) → git-доступ
-агентов → сборка `.env`/`.env.watchdog` → health.
-
-```bash
-python3 scripts/bootstrap_bundle.py            # план + preflight-диагностика (ноль мутаций)
-python3 scripts/bootstrap_bundle.py apply      # полный прогон
-```
-
-**Manual-step чекпоинты Plane CE** (API первичной инициализации в CE нет;
-каждый чекпоинт: точная инструкция → подтверждение → верификация результата
-API-пробой, молчаливый пропуск запрещён):
-1. **instance setup** — открыть Plane UI, зарегистрировать первого
-   пользователя (станет администратором инстанса);
-2. **workspace** — создать workspace, ввести его slug в bootstrap;
-3. **API-токен** — Workspace Settings → API tokens, вставить значение в
-   bootstrap (ввод скрыт; уходит в `ORCH_PLANE_API_TOKEN`);
-4. **workspace-webhook** — bootstrap регистрирует сам (запись в Postgres
-   инсталляции, путь Б канона `LITE_SETUP.md` §5.4) и проверяет; при отказе —
-   честный ручной шаг с той же проверкой;
-5. **порядок статусов на доске** — drag-and-drop по отчёту onboard
-   (`docs/operations/ONBOARDING.md`).
-
-Exit-коды: `0` — успех; `2` — остановка на manual-step/предусловии (выполните
-шаг и перезапустите `apply` — завершённые шаги пропускаются, повторный запуск
-безопасен); `1` — ошибка. Пароль админ-бота Gitea — ключ `GITEA_ADMIN_PASSWORD`
-в `deploy/bundled/.env` (права 600; вход в UI Gitea под
-`GITEA_ADMIN_USERNAME`).
-
-**Проверка:**
-
-```bash
-python3 scripts/bootstrap_bundle.py verify && echo "bootstrap: PASS"
-```
-
-`verify` зелёный (health/queue/metrics + onboard verify) — PASS; exit 2 —
-остались ручные пункты отчёта; exit 1 — FAIL (§14).
-
----
-
-## 8. LLM (claude CLI)
-
-Канон — `LITE_SETUP.md` §7 (полностью применим; не дублируется). Кратко: на
-хост ставятся claude-code + node, выполняется интерактивный логин CLI; пути
-прописываются в `deploy/bundled/.env` (это источники маунтов контейнера орка):
-`ORCH_HOST_CLAUDE_CODE_DIR`, `ORCH_HOST_NODE_BIN`, `ORCH_HOST_CLAUDE_DIR`,
-`ORCH_HOST_CLAUDE_JSON`.
-
-```bash
-claude --version
-docker compose -f deploy/bundled/docker-compose.yml exec orchestrator /usr/bin/claude --version
-```
-
-**Проверка:** обе команды печатают версию — PASS; вторая падает — пути в
-`deploy/bundled/.env` не указывают на фактические каталоги хоста (§14.4).
-
----
-
-## 9. Telegram
-
-Канон — `LITE_SETUP.md` §8 (два независимых бота, C-1: токен орка для watchdog
-переиспользовать запрещено). Ключи орка (`ORCH_TELEGRAM_BOT_TOKEN`,
-`ORCH_TELEGRAM_CHAT_ID`) — в корневой `.env`; ключи watchdog
-(`WATCHDOG_TG_BOT_TOKEN`, `WATCHDOG_TG_CHAT_ID`) — **только** в `.env.watchdog`
-(файл-носитель, `LITE_SETUP.md` §4.3). Шаг опционален: пустые токены =
-деградация только нотификаций.
-
-```bash
-grep -E '^ORCH_TELEGRAM_(BOT_TOKEN|CHAT_ID)=' .env
-grep -E '^WATCHDOG_TG_(BOT_TOKEN|CHAT_ID)=' .env.watchdog
-docker compose -f deploy/bundled/docker-compose.yml up -d orchestrator orchestrator-watchdog
-```
-
-**Проверка:** ключи заполнены и контейнеры пересозданы → тестовое сообщение от
-обоих ботов (`getMe` — команды в `LITE_SETUP.md` §8) — PASS; пусто — осознанный
-PASS без нотификаций.
-
----
-
-## 10. Онбординг следующих проектов
-
-Sandbox-проект создал bootstrap (§7). Каждый следующий проект заказчика —
-штатный runbook `docs/operations/ONBOARDING.md` поверх bundle-инсталляции; для
-команд из чекаута: Plane/Gitea доступны на `localhost`-портах §2, webhook-URL —
-in-network `http://orchestrator:8500/webhook/gitea`.
-
-```bash
-. .venv/bin/activate    # venv создан bootstrap'ом (§7)
-python3 scripts/onboard_project.py plan \
-  --name "<имя проекта>" --repo <repo> --prefix <PREFIX> \
-  --stack "<стек>" --test-cmd "<команда тестов>" \
-  --prod-port <порт-прода> --staging-port <порт-staging> \
-  --webhook-url http://orchestrator:8500/webhook/gitea
-# план устроил → apply → verify (как в LITE_SETUP.md §10), затем:
-# строку ORCH_PROJECTS_JSON из отчёта — в .env и пересоздать орк:
-docker compose -f deploy/bundled/docker-compose.yml up -d --force-recreate orchestrator
-```
-
-**Проверка:** `verify` зелёный; `GET /queue` отвечает после пересоздания — PASS.
-
----
-
-## 11. Smoke
-
-Процедура — чек-лист `docs/operations/REPLICATION.md` §4 (шаги 0–5; шаг 6 «до
-`done`» — опционально) поверх bundle-инсталляции, без форка. Минимальный сигнал
-«конвейер доехал»: issue в sandbox-проекте Plane → статус **To Analyse** →
-артефакты `01`–`04` в ветке задачи.
-
-```bash
-curl -fsS http://127.0.0.1:8500/health
-curl -fsS http://127.0.0.1:8500/queue   | python3 -m json.tool | head -30
-curl -fsS http://127.0.0.1:8500/metrics | python3 -m json.tool | head -10
-# создать issue в Plane (порт 8080) → перевести в «To Analyse», затем:
-curl -fsS http://127.0.0.1:8500/queue | python3 -m json.tool | head -40   # job появился
-git -C deploy/bundled/repos/sandbox fetch origin
-git -C deploy/bundled/repos/sandbox ls-tree --name-only origin/<ветка-задачи> "docs/work-items/<id>/"
-```
-
-**Проверка:** оба направления связности живы — job в `/queue` (Plane→орк
-доехал), `ls-tree` показывает `01-brd.md` … `04-test-plan.yaml` (орк→Gitea
-пишет; Gitea→орк события идут) — PASS. Любой шаг FAIL → тираж FAIL: соберите
-`docker compose -f deploy/bundled/docker-compose.yml logs --tail 100 orchestrator`
-и снапшот `GET /queue`, разбор — §14. (Порты замените, если меняли `BUNDLE_*`.)
-
----
-
-## 12. Stateless-проверка
-
-**Нормативно: данные/задачи/секреты/БД боевого (исходного) хоста НЕ
-переносятся** (зеркало `docs/operations/REPLICATION.md` §5). Все тома bundle
-созданы заново при первом `up`; секреты — только свежевыпущенные (§5); в
-Plane/Gitea инсталляции нет чужих задач/репо/пользователей.
-
-```bash
-docker volume ls --format '{{.Name}}' | grep '^orchestrator-bundle' # только тома этой инсталляции
-curl -fsS http://127.0.0.1:8500/queue | python3 -m json.tool        # счётчики нулевые
-```
-
-**Проверка:** в `/queue` нулевые счётчики и ни одной чужой задачи (никаких
-work-item исходного хоста) — PASS. Чужая задача/перенесённый файл БД — FAIL:
-инсталляция собрана не stateless, выполните полный сброс (§13) и повторите.
-
----
-
-## 13. Остановка и полный сброс
-
-Teardown — **только эта документированная процедура** (в bootstrap delete-режима
-сознательно нет, ADR-001 D9).
-
-**Остановка (обратимая):**
-
-```bash
-docker compose -f deploy/bundled/docker-compose.yml down
-```
-
-**Проверка:** `docker compose -f deploy/bundled/docker-compose.yml ps` пуст;
-тома целы (`docker volume ls | grep orchestrator-bundle`) — PASS.
-
-**Полный сброс (НЕОБРАТИМО — удаляет все данные Plane/Gitea/орка):**
-
-```bash
-docker compose -f deploy/bundled/docker-compose.yml down -v
-rm -rf deploy/bundled/data deploy/bundled/repos
-rm -f deploy/bundled/.env .env .env.watchdog
-```
-
-**Проверка:** `docker volume ls --format '{{.Name}}' | grep -c '^orchestrator-bundle'`
-→ `0`; live-конфигов нет — PASS (хост чист, можно разворачивать заново с §5).
-
----
-
-## 14. Траблшутинг
-
-Формат: симптом → диагностика → лечение.
-
-**14.1. Webhook не доходит (issue в Plane есть, job в `/queue` нет).**
-
-```bash
-docker compose -f deploy/bundled/docker-compose.yml logs --tail 50 orchestrator | grep -i "webhook\|signature"
-docker compose -f deploy/bundled/docker-compose.yml exec -T plane-db \
-  psql -U plane -d plane -c "SELECT url, is_active FROM webhooks;"
-```
-
-Лечение: (а) нет строки webhook → §7 чекпоинт 4; (б) URL не
-`http://orchestrator:8500/webhook/plane` → исправьте на in-network URL;
-(в) 401/HMAC → секрет в Plane обязан байт-в-байт совпадать с
-`ORCH_PLANE_WEBHOOK_SECRET` корневого `.env`. Для Gitea-направления проверьте
-Recent Deliveries в настройках hook'а репо; помните про
-`GITEA__webhook__ALLOWED_HOST_LIST=orchestrator` в bundle-compose (без него
-Gitea молча режет вебхуки в приватные адреса).
-
-**14.2. Не хватает RAM / OOM (контейнеры Plane в рестарт-цикле).**
-
-```bash
-free -g && docker stats --no-stream | head -20
-docker compose -f deploy/bundled/docker-compose.yml ps
-```
-
-Лечение: минимум §2 (8 GB; Plane ≈ 14 контейнеров). Меньше — добавьте RAM/swap;
-preflight bootstrap отказывает заранее именно поэтому.
-
-**14.3. Порт занят (`up` падает с bind error).**
-
-```bash
-ss -ltnp | grep -E ':(8500|8080|3000)\b'
-```
-
-Лечение: смените `BUNDLE_ORCH_PORT`/`BUNDLE_PLANE_PORT`/`BUNDLE_GITEA_HTTP_PORT`
-в `deploy/bundled/.env` и повторите `up`/bootstrap.
-
-**14.4. claude не найден / агент падает на старте.**
-
-```bash
-docker compose -f deploy/bundled/docker-compose.yml exec orchestrator /usr/bin/claude --version
-ls "$(grep '^ORCH_HOST_CLAUDE_CODE_DIR=' deploy/bundled/.env | cut -d= -f2)"
-```
-
-Лечение: пути `ORCH_HOST_*` в `deploy/bundled/.env` обязаны указывать на
-фактические каталоги хоста; креды CLI читаемы uid'ом `ORCH_RUN_UID` (канон —
-`LITE_SETUP.md` §7/§13.3); после правки — `up -d --force-recreate orchestrator`.
-
-**14.5. Миграции Plane не завершились (bootstrap падает на ожидании).**
-
-```bash
-docker compose -f deploy/bundled/docker-compose.yml logs --tail 50 migrator plane-db
-docker compose -f deploy/bundled/docker-compose.yml ps plane-db plane-mq plane-redis
-```
-
-Лечение: чаще всего — нехватка RAM/диска (§14.2) или невыпущенные секреты
-(пустой `POSTGRES_PASSWORD` → postgres не стартует; прогоните §7, который
-заполняет креды ДО `up`). После лечения — повторный `apply` (идемпотентен).
-
-**14.6. PR задачи не мержится / HOLD.** Branch protection на `main` в Gitea
-**НЕ включать** — норматив `LITE_SETUP.md` §6.4 (ломает PR-merge API
-merge-актора); bundle-Gitea конфигурируется тем же правилом.
-
-```bash
-curl -fsS -H "Authorization: token $ORCH_GITEA_TOKEN" \
-  "http://127.0.0.1:3000/api/v1/repos/<owner>/<repo>/branch_protections" | python3 -m json.tool
-```
-
-Лечение: непустой список правил → удалить (канон `LITE_SETUP.md` §6.4/§13.7).
-
----
-
-*Golden source Bundled-тиража (ORCH-103, ADR-001 D10). **Норматив сопровождения
-(NFR-5):** меняешь шаги Bundled-тиража (состав bundle-compose, ключи
-`deploy/bundled/.env.example`, шаги bootstrap, smoke) → обнови этот док В ТОМ ЖЕ
-PR. Полноту и гигиену держит `tests/test_bundled_setup_doc.py`; кирпичи-каноны:
-`LITE_SETUP.md` (§5–§8 — подключения), `docs/operations/ONBOARDING.md` (статусы
-§1, онбординг), `docs/operations/REPLICATION.md` (карта env §2, секреты §3,
-smoke §4), `deploy/bundled/.env.example` + `.env.example` /
-`.env.watchdog.example` (каноны ключей).*

docs/deployment/LITE_SETUP.md

@@ -1,596 +0,0 @@
-# LITE_SETUP — Lite-тираж: оркестратор + watchdog на вашей инфраструктуре (ORCH-102)
-
-> **Golden source Lite-тиража (Type A эпика ORCH-10).** Сквозной маршрут
-> «голый хост → работающий конвейер» для внешнего оператора/заказчика. Каждый шаг —
-> исполняемая команда + явная проверка результата (**Проверка:** / PASS / FAIL).
-> Хост-специфика в командах — только плейсхолдеры `<...>` и `$ENV_VAR`.
-> Тираж **stateless**: данные/задачи/секреты исходного (боевого) хоста **НЕ переносятся**
-> ни на одном шаге — всё создаётся заново (§12).
-
----
-
-## 1. Рамка Lite
-
-**Что разворачиваем:** два контейнера платформы — `orchestrator` (конвейер, порт
-`ORCH_DEPLOY_PROD_TARGET_PORT`, дефолт 8500) и `orchestrator-watchdog`
-(независимый sidecar-мониторинг). Третий сервис `orchestrator-staging` существует в том же
-compose-файле, но строго за профилем `staging` и в базовом Lite-контуре не поднимается (§9).
-
-**Что заказчик ставит и администрирует сам** (вне этой инструкции — как продукты):
-- **Plane** (task-management) — своя инсталляция; здесь только её *подключение* (§5);
-- **Gitea** (git-хостинг) — своя инсталляция; здесь только её *подключение* (§6);
-- **Telegram-боты** (нотификации) — свои боты (§8);
-- **LLM-доступ** (claude CLI + node) — свой дистрибутив и аутентификация (§7).
-
-**Границы слоёв тиража** (10-common vs Lite vs Bundled) — `docs/operations/REPLICATION.md` §1.
-Этот док собирает кирпичи 10-common (карта env, секреты, smoke) в один маршрут и не форкает их.
-
-**Платформенные конвенции (не менять):**
-- репо платформы обязан называться **`orchestrator`** (узел безопасности `SELF_HOSTING_REPO`);
-- имена compose-сервисов/профиля (`orchestrator`, `orchestrator-watchdog`,
-  `orchestrator-staging`, профиль `staging`) — константы платформы;
-- контейнерные пути (`/app/data`, `/repos`, `/opt/claude-code`) — layout контейнера,
-  не хост-значения; не параметризуются.
-
----
-
-## 2. Предусловия хоста
-
-Поддерживаемый контур: **Linux x86_64, Docker Engine + Compose v2, git, python3, node** +
-дистрибутив claude-code на хосте. Вне контура — вне гарантии Lite. Каждое предусловие —
-команда проверки; все проверки PASS → можно переходить к §3.
-
-**2.1. ОС и базовые зависимости.**
-
-```bash
-uname -sm                      # Linux x86_64
-docker --version               # Docker Engine
-docker compose version         # Compose v2
-git --version
-python3 --version              # 3.x (для scripts/*.py)
-node --version                 # путь к бинарю станет ORCH_HOST_NODE_BIN
-```
-
-**Проверка:** все команды отвечают версиями без ошибок — PASS; любая отсутствует — FAIL
-(доставить пакет средствами вашего дистрибутива).
-
-**2.2. Пользователь-владелец и uid/gid (инвариант ORCH-040).** Контейнеры бегут под
-`ORCH_RUN_UID:ORCH_RUN_GID` — это обязан быть uid:gid владельца каталога репозиториев
-`ORCH_HOST_REPOS_DIR`, иначе git-артефакты конвейера не запишутся.
-
-```bash
-id -u <deploy-user>; id -g <deploy-user>     # значения для ORCH_RUN_UID / ORCH_RUN_GID
-mkdir -p <путь-каталога-репозиториев>        # станет ORCH_HOST_REPOS_DIR
-stat -c '%u:%g' <путь-каталога-репозиториев> # обязан совпасть с ORCH_RUN_UID:ORCH_RUN_GID
-```
-
-**Проверка:** uid:gid владельца каталога = будущие `ORCH_RUN_UID`/`ORCH_RUN_GID` — PASS.
-
-**2.3. Группа docker (доступ к docker.sock).**
-
-```bash
-getent group docker            # третье поле — gid, станет ORCH_DOCKER_GID
-```
-
-**Проверка:** строка вида `docker:x:<gid>:...` есть — PASS; группы нет — FAIL
-(установите Docker корректно / создайте группу).
-
-**2.4. Каталог ssh-ключей деплой-хука** (понадобится для git-push артефактов агентов и
-деплой-хуков; монтируется в `$HOME/.ssh` акторов).
-
-```bash
-mkdir -p <путь-ssh-каталога>                 # станет ORCH_HOST_SSH_DIR
-ssh-keygen -t ed25519 -f <путь-ssh-каталога>/id_ed25519 -N "" -C "orchestrator@<host>"
-ls -l <путь-ssh-каталога>                    # ключи читаемы пользователем из 2.2
-```
-
-**Проверка:** каталог существует, ключи на месте, владелец — пользователь из 2.2 — PASS.
-Публичный ключ добавьте в Gitea (Settings → SSH Keys) на шаге §6.
-
-**2.5. Свободные порты** (дефолты платформы: 8500 — прод, 8501 — staging).
-
-```bash
-ss -ltn | grep -E ':(8500|8501)\b' || echo "ports free"
-```
-
-**Проверка:** вывод `ports free` — PASS. Порты заняты → выберите другие и на шаге §4
-синхронно задайте `ORCH_DEPLOY_PROD_TARGET_PORT` ⇄ `WATCHDOG_METRICS_URL` ⇄
-`ORCH_POST_DEPLOY_BASE_URL` (и `ORCH_STAGING_PORT` ≠ прод-порт — guard ORCH-058 fail-closed).
-
----
-
-## 3. Перенос кода
-
-Переносится **только код** — чекаут репо `orchestrator`. **НИКАКИХ** данных, БД или `.env`
-с исходного хоста (норматив §12). Watchdog отдельно не переносится: его код — каталог
-`watchdog/` того же репо, образ собирается локально compose'ом.
-
-```bash
-git clone <ORCHESTRATOR_GIT_URL> <путь-чекаута>   # путь станет ORCH_DEPLOY_HOST_REPO_PATH
-cd <путь-чекаута>
-```
-
-Конкретный канал дистрибуции (`<ORCHESTRATOR_GIT_URL>` — зеркало/архив/доступ к
-Gitea поставщика) согласуйте с поставщиком платформы; опционально — `--branch <тег-среза>`.
-
-**Проверка:**
-
-```bash
-git -C <путь-чекаута> log --oneline -1            # коммит виден
-ls <путь-чекаута>/docker-compose.yml <путь-чекаута>/watchdog/Dockerfile \
-   <путь-чекаута>/.env.example <путь-чекаута>/.env.watchdog.example
-```
-
-Все файлы на месте — PASS.
-
----
-
-## 4. Конфигурация
-
-`.env` собирается **с нуля от канона `.env.example`** (100% ключей старта; полная карта
-переменных и их семантика — `docs/operations/REPLICATION.md` §2). Дефолт каждого ключа =
-значению исходного хоста, поэтому задаёте только то, что отличается у вас.
-
-**4.1. Создать `.env` и выпустить webhook-секреты.**
-
-```bash
-cd <путь-чекаута>
-cp .env.example .env
-python3 scripts/gen_secrets.py        # печатает свежие ORCH_PLANE_WEBHOOK_SECRET / ORCH_GITEA_WEBHOOK_SECRET
-```
-
-Вставьте оба напечатанных значения в `.env`. Секреты выпускаются **только заново** —
-боевые не копируются (§12).
-
-**4.2. Обязательные ключи нового хоста** (заполняются в `.env` по ходу §5–§8):
-
-| Группа | Ключи | Откуда |
-|--------|-------|--------|
-| Plane | `ORCH_PLANE_API_URL`, `ORCH_PLANE_WEB_URL`, `ORCH_PLANE_WORKSPACE_SLUG`, `ORCH_PLANE_API_TOKEN` | §5 |
-| Gitea | `ORCH_GITEA_URL`, `ORCH_GITEA_PUBLIC_URL`, `ORCH_GITEA_OWNER`, `ORCH_GITEA_TOKEN` | §6 |
-| Webhook-секреты | `ORCH_PLANE_WEBHOOK_SECRET`, `ORCH_GITEA_WEBHOOK_SECRET` | 4.1 (`gen_secrets.py`) |
-| Telegram | `ORCH_TELEGRAM_BOT_TOKEN`, `ORCH_TELEGRAM_CHAT_ID` | §8 |
-| Реестр проектов | `ORCH_PROJECTS_JSON` — **обязателен**: встроенный fallback несёт Plane-UUID исходного хоста | §10 |
-| Хост-параметры | `ORCH_AGENT_HOME_DIR`, `ORCH_HOST_REPOS_DIR`, `ORCH_HOST_CLAUDE_DIR`, `ORCH_HOST_CLAUDE_JSON`, `ORCH_HOST_SSH_DIR`, `ORCH_HOST_CLAUDE_CODE_DIR`, `ORCH_HOST_NODE_BIN`, `ORCH_RUN_UID`, `ORCH_RUN_GID`, `ORCH_DOCKER_GID`, `ORCH_DEPLOY_HOST_REPO_PATH`, `ORCH_AGENT_GIT_NAME`, `ORCH_GIT_EMAIL_DOMAIN` | значения из §2–§3 |
-| Порты | `ORCH_DEPLOY_PROD_TARGET_PORT` ⇄ `WATCHDOG_METRICS_URL` ⇄ `ORCH_POST_DEPLOY_BASE_URL`; `ORCH_STAGING_PORT` ≠ прод-порт | §2.5 |
-
-**4.3. Конфиг sidecar-watchdog — отдельный файл-носитель.** Sidecar-контейнер читает
-**ТОЛЬКО `.env.watchdog`**; ключ `WATCHDOG_ENABLED` (и любой другой `WATCHDOG_*`),
-положенный в `.env`, для sidecar **инертен**.
-
-```bash
-cp .env.watchdog.example .env.watchdog
-# заполнить два ключа: WATCHDOG_TG_BOT_TOKEN / WATCHDOG_TG_CHAT_ID (бота создадим в §8)
-```
-
-**Проверка (резолв всей конфигурации):**
-
-```bash
-docker compose config >/dev/null && echo "compose config: PASS"
-```
-
-`PASS` без ошибок интерполяции — конфигурация согласована; ошибка — FAIL (ищите
-незакрытую кавычку/невалидный JSON в `ORCH_PROJECTS_JSON`).
-
----
-
-## 5. Подключение Plane
-
-Инсталляция Plane — ваша; платформа подключается к ней API-токеном и webhook'ом.
-
-**5.1. Workspace и проект.** Создайте workspace (его slug → `ORCH_PLANE_WEB_URL` /
-`ORCH_PLANE_WORKSPACE_SLUG`) и проект под вашу разработку — через UI Plane.
-
-```bash
-# базовая доступность API из хоста оркестратора:
-curl -fsS "$ORCH_PLANE_API_URL/api/v1/workspaces/<workspace-slug>/projects/" \
-  -H "X-API-Key: <plane-api-token>" | head -c 200
-```
-
-**Проверка:** HTTP 200 и JSON со списком проектов — PASS; 401/403 — токен (5.2) ещё не
-выпущен или не имеет прав.
-
-**5.2. API-токен.** Plane UI → Workspace Settings → API tokens → выпустить токен →
-`ORCH_PLANE_API_TOKEN` в `.env`. Токен должен иметь право создавать проекты/статусы
-(нужно для `onboard_project.py apply`, §10).
-
-**5.3. Модель статусов — НЕ вручную.** Конвейеру нужны **22 канонических статуса** с
-точными именами и группами; их создаёт `python3 scripts/onboard_project.py apply` (§10),
-полная таблица — `docs/operations/ONBOARDING.md` §1 (golden source; здесь не дублируется).
-Два имени фиксируем явно, потому что они **fail-closed** (без них ветка просто не
-активируется, без ошибки): **`Confirm Deploy`** (человеческий гейт прод-деплоя) и
-**`STOP`** (отмена задачи; обязан быть в группе `cancelled`).
-
-```bash
-# после §10 — проверить, что статусы созданы:
-curl -fsS "$ORCH_PLANE_API_URL/api/v1/workspaces/<workspace-slug>/projects/<project-uuid>/states/" \
-  -H "X-API-Key: $ORCH_PLANE_API_TOKEN" | python3 -m json.tool | grep -c '"name"'
-```
-
-**Проверка:** счётчик имён = 22 (или больше, если в проекте остались дефолтные статусы
-Plane) и среди них `Confirm Deploy` и `STOP` — PASS.
-
-**5.4. Webhook + HMAC.** Приёмник — `POST https://<orchestrator-public-host>/webhook/plane`;
-подпись — заголовок `X-Plane-Signature` (HMAC-SHA256, hex digest); секрет — значение
-`ORCH_PLANE_WEBHOOK_SECRET` из 4.1. События: Issue, Issue Comment.
-
-**Каверза Plane CE:** webhook **не экспонирован во внешнем `/api/v1`** — настраивается
-одним из двух путей.
-
-*Путь А — UI (если ваша сборка Plane его показывает):* Workspace Settings → Webhooks →
-Add Webhook → URL + Secret (значение `ORCH_PLANE_WEBHOOK_SECRET`) → события Issue,
-Issue Comment → Save.
-
-*Путь Б — прямой SQL в Postgres инсталляции Plane:*
-
-```bash
-WORKSPACE_ID=$(docker exec -e PGPASSWORD=<plane-db-password> <plane-db-container> \
-  psql -U plane -d plane -t -A -c "SELECT id FROM workspaces WHERE slug='<workspace-slug>'")
-WEBHOOK_ID=$(cat /proc/sys/kernel/random/uuid)
-docker exec -e PGPASSWORD=<plane-db-password> <plane-db-container> psql -U plane -d plane -c "
-INSERT INTO webhooks (id, created_at, updated_at, deleted_at, workspace_id, url, is_active,
-  secret_key, project, issue, module, cycle, issue_comment, is_internal, version)
-VALUES ('${WEBHOOK_ID}', NOW(), NOW(), NULL, '${WORKSPACE_ID}',
-  'https://<orchestrator-public-host>/webhook/plane',
-  true, '<значение ORCH_PLANE_WEBHOOK_SECRET>', true, true, false, false, true, false, 'v1');
-"
-```
-
-**Проверка:**
-
-```bash
-docker exec -e PGPASSWORD=<plane-db-password> <plane-db-container> psql -U plane -d plane -c \
-  "SELECT url, is_active FROM webhooks;"
-```
-
-Строка с вашим URL и `is_active = t` — PASS. Сквозная проверка доставки — §11 (smoke);
-generic-образец команд и формат подписи — `docs/operations/SETUP_WEBHOOKS.md`.
-
----
-
-## 6. Подключение Gitea
-
-**6.1. Токен.** Gitea UI → Settings → Applications → Generate Token, scope: `repo`,
-`admin:repo_hook` → `ORCH_GITEA_TOKEN` в `.env`.
-
-```bash
-curl -fsS -H "Authorization: token $ORCH_GITEA_TOKEN" "$ORCH_GITEA_URL/api/v1/user" | head -c 200
-```
-
-**Проверка:** HTTP 200 с JSON вашего пользователя — PASS; владелец репозиториев
-(организация/пользователь) → `ORCH_GITEA_OWNER`, браузерный URL → `ORCH_GITEA_PUBLIC_URL`.
-
-**6.2. Репо проекта.** Создаёт `onboard_project.py apply` (§10) — или вручную (пустой
-репо + initial push). Чекаут обязан появиться в `$ORCH_HOST_REPOS_DIR/<repo>` (общий
-каталог репозиториев из §2.2). Публичный ключ из §2.4 добавьте в Gitea
-(Settings → SSH Keys), чтобы акторы могли пушить.
-
-```bash
-git -C "$ORCH_HOST_REPOS_DIR" clone <git-url-репо-проекта> <repo>
-stat -c '%u:%g' "$ORCH_HOST_REPOS_DIR/<repo>"     # владелец = ORCH_RUN_UID:ORCH_RUN_GID
-```
-
-**Проверка:** чекаут на месте, владелец совпадает — PASS.
-
-**6.3. Per-repo webhook.** Создаёт `onboard_project.py apply` (§10). Параметры (если
-вручную): URL `https://<orchestrator-public-host>/webhook/gitea`, content type `json`,
-события **`push` / `pull_request` / `status`**, branch filter `*`, подпись —
-`X-Gitea-Signature` (HMAC-SHA256). Секрет — **ОДИН глобальный `ORCH_GITEA_WEBHOOK_SECRET`
-на ВСЕ репо** (приёмник валидирует только его; «свой секрет на репо» сломал бы HMAC
-остальных).
-
-```bash
-curl -fsS -H "Authorization: token $ORCH_GITEA_TOKEN" \
-  "$ORCH_GITEA_URL/api/v1/repos/<owner>/<repo>/hooks" | python3 -m json.tool
-```
-
-**Проверка:** hook с вашим URL и тремя событиями существует, `active: true` — PASS.
-
-**6.4. Норматив защиты `main` (ВАЖНО).** **Branch protection на `main` НЕ включать**
-(никаких required-approvals / required-status-checks): merge-актор конвейера мержит PR
-строго через Gitea PR-merge API (INV-4), и protection-правила дают 405/409-класс отказов →
-ложные HOLD задач (ADR D10 ORCH-009). **pre-receive хуки платформа не вводит** и не
-проверяет — защита `main` держится конвенцией (агенты не пушат `main`) + скоупом токенов.
-
-```bash
-curl -fsS -H "Authorization: token $ORCH_GITEA_TOKEN" \
-  "$ORCH_GITEA_URL/api/v1/repos/<owner>/<repo>/branch_protections" | python3 -m json.tool
-```
-
-**Проверка:** пустой список `[]` — PASS; есть правила на `main` — FAIL (удалите их,
-симптом «PR не мержится / HOLD» — §13.7).
-
----
-
-## 7. LLM (claude CLI)
-
-Агенты конвейера — процессы claude CLI **внутри контейнера**, но дистрибутив, node и
-аутентификация живут **на хосте** и пробрасываются маунтами (источники маунтов =
-ключи `.env`).
-
-**7.1. Дистрибутив claude-code и node.** Установите claude-code (npm-дистрибутив
-Anthropic) и node на хост. Пути → `.env`:
-
-```bash
-which node                                   # → ORCH_HOST_NODE_BIN
-npm root -g                                  # каталог глобальных модулей
-ls "<npm-root>/@anthropic-ai/claude-code"    # → ORCH_HOST_CLAUDE_CODE_DIR
-```
-
-**Проверка:** каталог дистрибутива существует и непуст — PASS. Внутри контейнера бинарь
-доступен как `ORCH_CLAUDE_BIN` (дефолт менять не нужно).
-
-**7.2. Аутентификация CLI.** Выполните первичный интерактивный логин claude CLI **на
-хосте** под пользователем из §2.2 (по инструкции Anthropic к claude-code). Логин создаёт
-каталог `~/.claude` и файл `~/.claude.json` — их пути задайте в `ORCH_HOST_CLAUDE_DIR` /
-`ORCH_HOST_CLAUDE_JSON`.
-
-```bash
-claude --version                                            # CLI работает
-sudo -u "#<uid-из-2.2>" test -r <путь-~/.claude>/.credentials.json && echo "creds: PASS"
-```
-
-**Проверка:** версия печатается; `creds: PASS` — креды читаемы uid'ом контейнера
-(иначе — `chown -R <uid>:<gid>` каталога, симптом §13.3).
-
-**7.3. Модели агентов.** Резолв модели/эффорта — только из конфига (ORCH-41/74):
-дефолты канона уже в `.env.example` (`ORCH_AGENT_MODEL_DEFAULT`,
-`ORCH_AGENT_EFFORT_DEFAULT` и per-агент ключи рядом) — менять не обязательно.
-
-```bash
-grep -E '^ORCH_AGENT_(MODEL|EFFORT)_DEFAULT=' .env
-```
-
-**Проверка:** оба ключа присутствуют и непусты — PASS.
-
----
-
-## 8. Telegram
-
-Каналов **два и они независимы** (C-1 ORCH-100): бот live-трекера оркестратора и
-**отдельный** бот sidecar-watchdog. Токен орка для watchdog переиспользовать
-**ЗАПРЕЩЕНО** — упавший орк не сможет сообщить о себе своим же ботом.
-
-**8.1. Бот трекера.** BotFather → `/newbot` → токен → `ORCH_TELEGRAM_BOT_TOKEN` в `.env`.
-
-```bash
-curl -fsS "https://api.telegram.org/bot<токен-трекера>/getMe"
-# напишите боту любое сообщение (или добавьте его в чат), затем:
-curl -fsS "https://api.telegram.org/bot<токен-трекера>/getUpdates" | python3 -m json.tool | grep -m1 '"id"'
-```
-
-**Проверка:** `getMe` → `"ok":true`; `id` чата из `getUpdates` → `ORCH_TELEGRAM_CHAT_ID` —
-PASS.
-
-**8.2. Watchdog-бот (отдельный).** BotFather → `/newbot` ещё раз → токен и chat-id →
-**`.env.watchdog`** (`WATCHDOG_TG_BOT_TOKEN` / `WATCHDOG_TG_CHAT_ID`). Помните о
-файле-носителе: эти ключи работают только в `.env.watchdog` (§4.3).
-
-```bash
-curl -fsS "https://api.telegram.org/bot<токен-watchdog>/getMe"
-grep -E '^WATCHDOG_TG_(BOT_TOKEN|CHAT_ID)=.+' .env.watchdog
-```
-
-**Проверка:** `getMe` → `"ok":true`; оба ключа в `.env.watchdog` непусты — PASS.
-
----
-
-## 9. Запуск
-
-**9.1. Базовый Lite-контур (дефолт): орк + watchdog.**
-
-```bash
-cd <путь-чекаута>
-docker compose config --services    # ровно: orchestrator, orchestrator-watchdog, orchestrator-staging
-docker compose up -d --build
-docker compose ps
-```
-
-**Проверка:** запущены **ровно два** контейнера — `orchestrator` и
-`orchestrator-watchdog`; `orchestrator-staging` НЕ поднялся (он строго за
-`profiles: [staging]`) — PASS. Поднялось что-то ещё/меньше — FAIL.
-
-**9.2. Health-чек контрактов.**
-
-```bash
-curl -fsS http://127.0.0.1:8500/health
-curl -fsS http://127.0.0.1:8500/queue   | python3 -m json.tool | head -20
-curl -fsS http://127.0.0.1:8500/metrics | python3 -m json.tool | head -10
-```
-
-**Проверка:** `/health` → HTTP 200, `"status":"ok"`; `/queue` → штатный JSON
-(счётчики очереди); `/metrics` → JSON со `"schema_version": 1` — PASS. (Порт замените,
-если меняли `ORCH_DEPLOY_PROD_TARGET_PORT`.)
-
-**9.3. Вилка staging (опционально).** Базовому контуру «гонять СВОИ проекты» staging
-**не нужен**. Он нужен ТОЛЬКО если вы регистрируете проект `orchestrator` (self-hosting
-развитие самой платформы у себя): стадия `deploy-staging` требует песочницу на
-`ORCH_STAGING_PORT` (изолированная БД `./data/staging`; guard ORCH-058: staging-порт ≠
-прод-порт, fail-closed).
-
-```bash
-cp .env.staging.example .env.staging      # заполнить по аналогии с .env
-docker compose --profile staging up -d orchestrator-staging
-curl -fsS http://127.0.0.1:8501/health
-```
-
-**Проверка (только для этой вилки):** `/health` staging → 200 — PASS.
-
----
-
-## 10. Регистрация проекта заказчика
-
-Onboarding-CLI создаёт Plane-проект с 22 статусами и лейблами (`autoApprove` /
-`autoDeploy` / `Bug`), Gitea-репо с webhook'ом, скелет репо (kit) и печатает merged-реестр.
-Полный runbook — `docs/operations/ONBOARDING.md`; Lite-последовательность:
-
-```bash
-cd <путь-чекаута>
-python3 scripts/onboard_project.py plan \
-  --name "<имя проекта>" --description "<зачем проект>" \
-  --repo <repo> --prefix <PREFIX> \
-  --stack "<стек>" --test-cmd "<команда тестов>" \
-  --prod-port <порт-прода-проекта> --staging-port <порт-staging-проекта> \
-  --webhook-url https://<orchestrator-public-host>/webhook/gitea
-# план устроил → тот же вызов с apply; затем read-only контроль:
-python3 scripts/onboard_project.py verify <те же аргументы>
-```
-
-**Проверка:** `apply` завершился без ошибок (exit 0; `2` = остались 🖐 ручные шаги — выполните
-их по отчёту), `verify` зелёный — PASS.
-
-Дальше реестр и рестарт:
-
-```bash
-# 1) строку ORCH_PROJECTS_JSON=[...] из отчёта apply вставить в .env (заменить целиком);
-# 2) дождаться тихого окна и управляемо перезапустить орк:
-curl -fsS http://127.0.0.1:8500/queue | python3 -m json.tool | head -20   # нет running-job
-docker compose up -d --force-recreate orchestrator
-# 3) убедиться, что инстанс жив и реестр подхвачен:
-curl -fsS http://127.0.0.1:8500/health
-curl -fsS http://127.0.0.1:8500/queue | python3 -m json.tool | head -20
-```
-
-**Проверка:** `/health` → 200 после рестарта; в Plane создан проект со статусами
-(см. §5.3), в Gitea — репо с webhook (§6.3) — PASS.
-
----
-
-## 11. Smoke: «конвейер доехал»
-
-Процедура — чек-лист `docs/operations/REPLICATION.md` §4 (шаги 0–5; шаг 6 «до `done`» —
-опционально), без форка; каждый шаг несёт явный PASS/FAIL. Lite-предусловия: §2–§10 этого
-дока выполнены, проект заказчика зарегистрирован (§10).
-
-Минимальный сигнал «конвейер доехал» (шаги 4–5 чек-листа): создайте issue в Plane-проекте
-и переведите в статус **To Analyse**, затем:
-
-```bash
-# задача появилась и analyst-job в очереди:
-curl -fsS http://127.0.0.1:8500/queue | python3 -m json.tool | head -40
-# по завершении стадии analysis — артефакты 01–04 в ветке задачи:
-git -C "$ORCH_HOST_REPOS_DIR/<repo>" fetch origin
-git -C "$ORCH_HOST_REPOS_DIR/<repo>" ls-tree --name-only origin/<ветка-задачи> "docs/work-items/<id-задачи>/"
-```
-
-**Проверка:** в `/queue` виден job задачи; `ls-tree` показывает `01-brd.md` …
-`04-test-plan.yaml` — PASS.
-
-**Итоговый вердикт:** все шаги чек-листа PASS ⇒ **тираж PASS**; любой шаг FAIL ⇒ тираж
-FAIL — соберите `docker logs orchestrator --tail 100` и снапшот `GET /queue`, разбор —
-§13.
-
----
-
-## 12. Stateless-проверка
-
-**Нормативно: данные/задачи/секреты боевого (исходного) хоста НЕ переносятся** (зеркало
-`docs/operations/REPLICATION.md` §5). БД создаётся **пустой** при первом старте; `.env` /
-`.env.staging` / `.env.watchdog` собраны с нуля (§4); секреты — только свежевыпущенные
-(`gen_secrets.py` + чек-лист внешних токенов `docs/operations/REPLICATION.md` §3).
-
-Проверка чистоты развёрнутого инстанса (выполнить ДО первой своей задачи):
-
-```bash
-ls -la <путь-чекаута>/data/                                  # БД появилась только после первого старта
-curl -fsS http://127.0.0.1:8500/queue | python3 -m json.tool # счётчики jobs нулевые
-```
-
-**Проверка:** в `/queue` нулевые счётчики и НИ ОДНОЙ задачи чужих проектов (никаких
-`ORCH-*`/`ET-*` исходного хоста) — PASS. Любая чужая задача/перенесённый файл БД — FAIL:
-инстанс собран не stateless, пересоберите `data/` с нуля.
-
----
-
-## 13. Траблшутинг первичной настройки
-
-Формат: симптом → команда диагностики → лечение.
-
-**13.1. Webhook отвечает 401 / HMAC mismatch.**
-
-```bash
-docker logs orchestrator --tail 50 2>&1 | grep -i "webhook\|signature\|401"
-```
-
-Лечение: секрет в `.env` (`ORCH_PLANE_WEBHOOK_SECRET` / `ORCH_GITEA_WEBHOOK_SECRET`)
-обязан **байт-в-байт** совпадать с секретом в настройке webhook'а (Plane §5.4 / Gitea
-§6.3); после правки `.env` — управляемый рестарт (§10). Формат подписи —
-`docs/operations/SETUP_WEBHOOKS.md`.
-
-**13.2. Задача в Plane создана, но в оркестраторе не появилась.**
-
-```bash
-curl -fsS http://127.0.0.1:8500/queue | python3 -m json.tool | head -30   # есть ли job
-docker logs orchestrator --tail 50 2>&1 | grep -i "ignored\|unknown project"
-grep ORCH_PROJECTS_JSON .env                                              # uuid вашего проекта в реестре?
-```
-
-Лечение: (а) проект отсутствует/с чужим UUID в `ORCH_PROJECTS_JSON` → поправить реестр
-(§10) + рестарт; (б) webhook не доставлен → Plane: `SELECT url, is_active FROM webhooks;`
-(§5.4), Gitea: Recent Deliveries в настройках hook'а; (в) подпись → §13.1.
-
-**13.3. claude CLI не найден / не аутентифицирован (агент падает на старте).**
-
-```bash
-docker exec orchestrator /usr/bin/claude --version
-sudo -u "#<uid-из-2.2>" test -r <путь-~/.claude>/.credentials.json && echo "creds: PASS"
-```
-
-Лечение: маунты указывают на фактические пути хоста (`ORCH_HOST_CLAUDE_CODE_DIR`,
-`ORCH_HOST_NODE_BIN`, `ORCH_HOST_CLAUDE_DIR`, `ORCH_HOST_CLAUDE_JSON` в `.env`); креды
-читаемы uid'ом из §2.2 (`chown -R <uid>:<gid>`); при невалидной сессии — повторный логин
-на хосте (§7.2) + `docker compose up -d --force-recreate orchestrator`.
-
-**13.4. `docker.sock: permission denied` в логах орка/watchdog.**
-
-```bash
-getent group docker          # фактический gid
-grep ORCH_DOCKER_GID .env    # gid в конфиге
-```
-
-Лечение: значения обязаны совпадать → выставить `ORCH_DOCKER_GID` = фактическому gid и
-`docker compose up -d --force-recreate`.
-
-**13.5. `Permission denied` при создании worktree (права `/repos`, ORCH-040/057).**
-
-```bash
-stat -c '%u:%g' "$ORCH_HOST_REPOS_DIR" "$ORCH_HOST_REPOS_DIR/<repo>"
-grep -E '^ORCH_RUN_(UID|GID)=' .env
-```
-
-Лечение: владелец каталога репо обязан совпадать с `ORCH_RUN_UID:ORCH_RUN_GID`
-(§2.2) → `chown -R <uid>:<gid> "$ORCH_HOST_REPOS_DIR"` (включая legacy root-owned файлы)
-и пересоздать контейнер.
-
-**13.6. Telegram молчит (нет карточек/алертов).**
-
-```bash
-curl -fsS "https://api.telegram.org/bot<токен-трекера>/getMe"
-curl -fsS "https://api.telegram.org/bot<токен-watchdog>/getMe"
-grep -E '^ORCH_TELEGRAM_(BOT_TOKEN|CHAT_ID)=.+' .env
-grep -E '^WATCHDOG_TG_(BOT_TOKEN|CHAT_ID)=.+' .env.watchdog
-```
-
-Лечение: оба бота отвечают `"ok":true`; chat-id корректен (бот добавлен в чат / получил
-сообщение); ключи watchdog-бота лежат именно в `.env.watchdog` (в `.env` они инертны,
-§4.3); пустой токен = режим «логи без отправки» (fail-safe, не ошибка).
-
-**13.7. PR задачи не мержится / задача в HOLD.** Первая проверка — **не включена ли
-branch protection на `main`** (§6.4):
-
-```bash
-curl -fsS -H "Authorization: token $ORCH_GITEA_TOKEN" \
-  "$ORCH_GITEA_URL/api/v1/repos/<owner>/<repo>/branch_protections" | python3 -m json.tool
-```
-
-Лечение: непустой список правил на `main` → удалить (норматив §6.4); merge выполняет
-PR-merge API оркестратора, ручной merge не требуется.
-
----
-
-*Golden source Lite-тиража (ORCH-102, ADR-001). **Норматив сопровождения (NFR-5):**
-меняешь шаги тиража (env-ключи, compose-сервисы, маршрут онбординга, smoke) → обнови
-этот док В ТОМ ЖЕ PR (правило агентов №2). Полноту и гигиену дока держит структурный
-анти-дрейф тест `tests/test_lite_setup_doc.py`; кирпичи-каноны: REPLICATION.md (карта
-env §2, секреты §3, smoke §4), ONBOARDING.md (статусы §1, онбординг), SETUP_WEBHOOKS.md
-(формат вебхуков), `.env.example` / `.env.watchdog.example` (канон ключей).*

docs/operations/INFRA.md

@@ -171,15 +171,8 @@ watchdog'а: **watchdog сигналит, pruner убирает**.
 | `ORCH_BUILD_CACHE_PRUNE_TIMEOUT_S` | таймаут ssh-команды prune, сек; дефолт `120` |
 | `ORCH_BUILD_CACHE_PRUNE_NOTIFY_MIN_GB` | Telegram при освобождении ≥ N ГБ; дефолт `0` (тихо) |
 | `DEPLOY_SSH_USER` / `_HOST` / `DEPLOY_HOOK_SCRIPT` | параметры деплой-хука |
-| `ORCH_AGENT_HOME_DIR` | ORCH-101: HOME всех акторских subprocess-env (агенты/finalizer/monitor) **и** таргет маунтов `.claude`/`.claude.json`/`.ssh` **и** `ARG APP_HOME` Dockerfile (группа ORCH-040 двигается согласованно); дефолт `/home/slin` |
-| `ORCH_AGENT_GIT_NAME` / `ORCH_GIT_EMAIL_DOMAIN` | ORCH-101: git-идентичность коммитов агентов (`claude-bot` @ `mva154.local`); системные акторы держат платформенные имена `deploy-finalizer`/`post-deploy-monitor` под тем же доменом |
-| `ORCH_STAGING_PORT` | ORCH-101: порт staging-инстанса (дефолт `8501`); читается и `image_freshness`, и compose `command:` staging; guard fail-closed при совпадении с прод-портом (ORCH-058 AC-9) |
-| `ORCH_HOST_CLAUDE_DIR` / `_CLAUDE_JSON` / `_SSH_DIR` | ORCH-101: host-источники bind-маунтов `~/.claude`, `~/.claude.json`, ssh-ключей (`/home/slin/.{claude,claude.json,orchestrator-ssh}`) |
-| `ORCH_HOST_CLAUDE_CODE_DIR` / `_NODE_BIN` | ORCH-101: host-пути дистрибутива claude-code и бинаря node (`/usr/lib/node_modules/@anthropic-ai/claude-code`, `/usr/bin/node`) |
-| `ORCH_RUN_UID` / `ORCH_RUN_GID` | ORCH-101: uid:gid контейнера (`user:`) + `ARG APP_UID/APP_GID` (дефолт `1000:1000`, ORCH-040) |
-| `ORCH_DOCKER_GID` | ORCH-101: gid docker-группы хоста для `group_add` (дефолт `999`; «МИНА 1» ORCH-040 — не удалять) |
 
-**Секреты — только в `.env` / `.env.staging` / `.env.watchdog` на хосте, в гит НЕ коммитятся.** Канон — `.env.example`, `.env.staging.example`, `.env.watchdog.example` (ORCH-102: sidecar-watchdog читает ТОЛЬКО `.env.watchdog`; `WATCHDOG_*` в `.env` для него инертен). Выпуск нового комплекта секретов для нового хоста — `scripts/gen_secrets.py` (боевые секреты не копируются). **Тираж платформы на новую инфру** (карта переменных, секреты, smoke-процедура, границы Lite/Bundled) — `docs/operations/REPLICATION.md` (ORCH-101); сквозная инструкция Lite-тиража для внешнего оператора («голый хост → конвейер», орк+watchdog) — `docs/deployment/LITE_SETUP.md` (ORCH-102). Когерентность портов при смене прод-порта: `ORCH_DEPLOY_PROD_TARGET_PORT` ⇄ `WATCHDOG_METRICS_URL` ⇄ `ORCH_POST_DEPLOY_BASE_URL`.
+**Секреты — только в `.env` / `.env.staging` на хосте, в гит НЕ коммитятся.** Канон — `.env.example`, `.env.staging.example`.
 
 ## Реестр проектов (`src/projects.py`, ORCH-6)
 Связывает Plane project id → gitea repo + work-item prefix. Источник: `ORCH_PROJECTS_JSON`, fallback — встроенный дефолт. Прод видит: `enduro-trails` (ET), `orchestrator` (ORCH). Staging видит ТОЛЬКО `orchestrator-sandbox` (SANDBOX) — изоляция.

docs/operations/ONBOARDING.md

@@ -1,200 +0,0 @@
-# ONBOARDING — turnkey-онбординг нового проекта (ORCH-009)
-
-> RUNBOOK. Полный чеклист подключения нового проекта к оркестратору одним проходом.
-> Исполнитель — оператор; инструмент — CLI `scripts/onboard_project.py`
-> (режимы `plan` — дефолт/dry-run, `apply`, `verify`). Каждый шаг, который CLI выполнить
-> не может, помечен **🖐 РУЧНОЙ ШАГ** и снабжён командой проверки результата.
-> Архитектура решения — см. «Ссылки» внизу.
-
-Запуск CLI — из корня чекаута репо orchestrator, в venv с `requirements.txt`:
-
-```bash
-python3 scripts/onboard_project.py plan \
-  --name "My Project" --description "зачем проект" \
-  --repo my-project --prefix MP \
-  --stack "Python 3.12 + FastAPI" --test-cmd "pytest tests/ -q" \
-  --prod-port 8600 --staging-port 8601 \
-  --webhook-url https://openclaw.mva154.duckdns.org/orchestrator/webhook/gitea
-```
-
-`plan` печатает полный план **без единой мутации** (ни сети-POST, ни записи на диск);
-`apply` — идемпотентный ensure (существующее → `skipped(exists)`, ничего не удаляется);
-exit-коды: `0` — чисто, `2` — есть `manual-step`/gap, `1` — ошибка.
-
----
-
-## 0. Предусловия
-
-Все значения — в `.env` на хосте (секреты в гит не попадают):
-
-| Переменная | Зачем | Проверка |
-|-----------|-------|----------|
-| `ORCH_PLANE_API_TOKEN` (+`ORCH_PLANE_API_URL`, `ORCH_PLANE_WORKSPACE_SLUG`) | создание/чтение проекта, статусов, лейблов | `curl -s -H "X-API-Key: $TOKEN" $URL/api/v1/workspaces/$SLUG/projects/ \| head -c 200` |
-| `ORCH_GITEA_TOKEN` (+`ORCH_GITEA_URL`) | создание репо + webhook | `curl -s -H "Authorization: token $TOKEN" $URL/api/v1/user \| head -c 200` |
-| `ORCH_GITEA_WEBHOOK_SECRET` | HMAC webhook (переиспользуется, один на все репо) | есть строка в `.env`; нет → `apply` сгенерирует и выведет |
-| `ORCH_PROJECTS_JSON` | текущий реестр — источник merged-вывода | `grep ORCH_PROJECTS_JSON .env` |
-
-Токен Plane должен иметь право создавать проекты в workspace; токен Gitea — создавать репо и
-hooks под выбранным owner (`--gitea-owner`, дефолт из конфига).
-
----
-
-## 1. Слой Plane: проект + статусы + лейблы
-
-Выполняет `apply` (или вручную при недоступности API CE — каждый отказ CLI помечает
-`manual-step`, не падает).
-
-1. **Проект**: создаётся с `identifier = --prefix`. Уже существует → передай
-   `--plane-project-id <uuid>` (ensure распознает и пропустит).
-2. **Статусы — точные канонические имена** (22, источник — `plane_sync._PLANE_NAME_TO_KEY`;
-   опечатка = тихая деградация fail-closed веток):
-
-   | Статус | Группа | | Статус | Группа |
-   |--------|--------|-|--------|--------|
-   | Backlog | `backlog` | | In Review | `started` |
-   | Todo | `unstarted` | | Blocked | `started` |
-   | To Analyse | `unstarted` | | Approved | `started` |
-   | In Progress | `started` | | Rejected | `started` |
-   | Analysis | `started` | | **Confirm Deploy** | `started` |
-   | Architecture | `started` | | Needs Input | `started` |
-   | Development | `started` | | Done | `completed` |
-   | Code-Review | `started` | | Cancelled | `cancelled` |
-   | Review | `started` | | **STOP** | **`cancelled`** |
-   | Testing | `started` | | Awaiting Deploy | `started` |
-   | Deploying | `started` | | Monitoring after Deploy | `started` |
-
-   ⚠️ Код-критично: `STOP` обязан быть в группе `cancelled` (иначе ветка отмены молча не
-   активируется); в терминальных группах (`completed`/`cancelled`) — ТОЛЬКО
-   Done/Cancelled/STOP, иначе terminal-detection ложно сочтёт живую задачу терминальной.
-3. **Лейблы**: `autoApprove`, `autoDeploy`, `Bug` (имена — из конфига оркестратора; их
-   отсутствие = fail-safe ручной режим / полный цикл).
-4. **🖐 РУЧНОЙ ШАГ — порядок статусов на доске**: drag-and-drop в UI (API не управляет
-   порядком). Проверка: открой доску проекта — колонки в порядке конвейера.
-5. **Workspace-webhook**: уже **существует** (один на весь workspace, создан на уровне
-   workspace заранее) — CLI его НЕ создаёт, только напоминает проверить:
-
-   ```bash
-   docker exec -e PGPASSWORD=plane plane-app-plane-db-1 psql -U plane -d plane -c \
-     "SELECT id, url, is_active FROM webhooks;"
-   ```
-
----
-
-## 2. Слой Gitea: репо + per-repo webhook
-
-1. **Репо** `--gitea-owner/--repo`: создаётся пустым (`auto_init=false`; ветку `main` создаст
-   initial push следующего слоя). Существует → `skipped(exists)`.
-2. **Per-repo webhook**: `events: push/pull_request/status`, `content_type: json`,
-   `branch_filter: *`, URL = `--webhook-url`. **Секрет переиспользуется** из
-   `ORCH_GITEA_WEBHOOK_SECRET` (приёмник валидирует ОДИН глобальный секрет на все репо;
-   новый секрет сломал бы HMAC существующих вебхуков). Секрета нет в env → CLI сгенерирует и
-   выведет строку для `.env` — **🖐 РУЧНОЙ ШАГ**: добавить её в `.env` (в гит не коммитить).
-   Формат и проверка — `docs/operations/SETUP_WEBHOOKS.md`. Проверка:
-
-   ```bash
-   curl -s -H "Authorization: token $ORCH_GITEA_TOKEN" \
-     "$ORCH_GITEA_URL/api/v1/repos/<owner>/<repo>/hooks" | python3 -m json.tool
-   ```
-3. **Branch protection `main` НЕ включать** (ADR D10): required-approvals/status-checks ломают
-   PR-merge API merge-актора конвейера (ложные HOLD). Защита держится конвенцией + скоупом
-   токенов.
-
----
-
-## 3. Слой kit: материализация + initial push
-
-1. `apply` рендерит kit (`onboarding/repo-skeleton/`, плейсхолдеры `{{NAME}}` из
-   `onboarding/placeholders.json`) во временный каталог, докладывает live-copy канона
-   (`docs/_templates/` 16 скелетов + `docs/_standards/` 3 стандарта — verbatim из текущего
-   чекаута, BR-2 «канон не форкается») и пушит **ТОЛЬКО в свежесозданный/пустой репо**
-   (единственный разрешённый push; коммит `feat: onboarding skeleton (ORCH-009 kit)`).
-2. Репо непустой → шаг помечается `manual-step`: **🖐 РУЧНОЙ ШАГ** — занеси недостающие
-   файлы обычным PR с ревью; поверх существующего контента ничего не пушится (BR-9).
-3. После рендера не должно остаться ни одного `{{...}}`: CLI падает на этом сам; повторная
-   проверка — `verify` (скан плейсхолдеров в файлах репо).
-
----
-
-## 4. Регистрация в реестре оркестратора
-
-> ⚠️ **САМЫЙ ВАЖНЫЙ РУЧНОЙ СЛОЙ.** CLI `.env` прода НЕ правит и контейнер НЕ рестартит
-> (инвариант NFR-2) — он только печатает готовую строку.
-
-1. **🖐 РУЧНОЙ ШАГ — env**: возьми из отчёта `apply` строку
-   `ORCH_PROJECTS_JSON=[...полный merged-массив...]` (существующие записи verbatim + новая в
-   конец; строка уже провалидирована фактическим парсером реестра) и замени ею строку в `.env`
-   оркестратора на хосте. Вставляется атомарно одной строкой — ручное слияние JSON не нужно.
-2. **🖐 РУЧНОЙ ШАГ — управляемый рестарт оркестратора**: реестр строится при импорте, нужна
-   перезагрузка процесса. **Self-hosting предупреждение: прод-контейнер один на ВСЕ проекты —
-   рестарт = групповое окно** (встаёт конвейер всех проектов). Выполняй осознанно: дождись
-   тихого окна (`GET /queue` — нет бегущих job), затем штатный рестарт по
-   `docs/operations/INFRA.md`. Проверка после рестарта:
-
-   ```bash
-   curl -s http://localhost:8500/health
-   curl -s http://localhost:8500/queue | python3 -m json.tool | head -30   # реестр жив, конвейер пуст/цел
-   ```
-3. TTL-self-heal статусов Plane (300с) рестарта НЕ требует: статусы/лейблы, созданные после
-   регистрации, подхватятся сами.
-
----
-
-## 5. Верификация
-
-1. **`verify`-режим CLI** (read-only):
-
-   ```bash
-   python3 scripts/onboard_project.py verify --name ... --repo ... --prefix ... \
-     --plane-project-id <uuid> --stack ... --test-cmd ... --prod-port ... --staging-port ... \
-     --webhook-url https://openclaw.mva154.duckdns.org/orchestrator/webhook/gitea
-   ```
-
-   Проверяет: запись реестра парсится и совпадает по полям; все 22 статуса резолвятся
-   (включая fail-closed `Confirm Deploy`/`STOP`); лейблы на месте; webhook существует и
-   активен; kit-файлы в репо (6 промптов, `AGENTS.md`, `INFRA.md`, `_templates`/`_standards`);
-   нет неразрешённых плейсхолдеров. Любой gap → exit `2` с перечнем.
-
-2. **Smoke на песочнице (ADR D8)** — контур: **staging-оркестратор (порт 8501, изолированная
-   БД `./data/staging`)** + одноразовый sandbox-проект (рекомендуемые имена: проект
-   `onboarding-smoke`, префикс `SMK`, репо `onboarding-smoke`):
-   1. Онборди sandbox самим CLI (слои 1–3 этого runbook).
-   2. **🖐 РУЧНОЙ ШАГ**: зарегистрируй sandbox в `ORCH_PROJECTS_JSON` **`.env.staging`**
-      (не прода!) и перезапусти staging-контейнер (он свободен от прод-инварианта):
-      `docker compose --profile staging up -d orchestrator-staging`.
-   3. Создай тестовую задачу в sandbox-проекте → доведи до стадии analysis в песочнице.
-   4. Критерий PASS: агент по своему промпту **прочитал доку проекта** (следы чтения
-      `CLAUDE.md`/`AGENTS.md` в выводе) и **записал артефакты** в `docs/work-items/SMK-…/`
-      по канону `PIPELINE_DOCS.md`.
-   5. Запротоколируй прогон в «Журнале smoke-прогонов» (ниже). Для приёмки ORCH-009 первый
-      протокол обязателен.
-
----
-
-## 6. Откат
-
-CLI ничего не удаляет (BR-9) — откат всегда ручной и осознанный:
-
-| Что создано | Как откатить | Проверка |
-|-------------|--------------|----------|
-| Plane-проект (+статусы/лейблы) | удалить проект в UI Plane | проект исчез из списка workspace |
-| Gitea-репо (+webhook) | удалить репо в UI/API Gitea (webhook умрёт вместе с ним) | `GET /api/v1/repos/<owner>/<repo>` → 404 |
-| Строка реестра | убрать запись из `ORCH_PROJECTS_JSON` в `.env` + управляемый рестарт (см. слой 4, то же групповое окно) | `GET /queue` — проекта нет в реестре |
-| Sandbox-артефакты smoke | удалить sandbox-проект/репо после прогона (или архивировать) | см. выше |
-
----
-
-## Журнал smoke-прогонов
-
-| Дата | Оператор | Параметры (проект/префикс/репо) | Контур | Результат (PASS/FAIL) | Протокол |
-|------|----------|----------------------------------|--------|------------------------|----------|
-| —    | —        | — (первый прогон фиксируется при приёмке ORCH-009) | staging 8501 | — | — |
-
----
-
-## Ссылки
-
-- Архитектура решения: `docs/work-items/ORCH-009/06-adr/ADR-001-turnkey-onboarding-kit-and-cli.md`
-  (D1…D11); сквозной ADR — `docs/architecture/adr/adr-0035-turnkey-project-onboarding.md`.
-- Устройство набора шаблонов и словарь плейсхолдеров: `onboarding/README.md`.
-- Формат вебхуков: `docs/operations/SETUP_WEBHOOKS.md`; топология и рестарты —
-  `docs/operations/INFRA.md`.

docs/operations/REPLICATION.md

@@ -1,155 +0,0 @@
-# REPLICATION — тираж платформы на новую инфраструктуру (ORCH-101)
-
-> RUNBOOK фундамента тиража (эпик ORCH-10, слой **10-common**). Как развернуть
-> оркестратор на чужом хосте **без правки кода**: переменные → секреты → smoke.
-> Тираж **stateless**: данные/БД/секреты боевого хоста НЕ переносятся ни на одном
-> шаге — на целевой инфре всё создаётся заново.
-
----
-
-## 1. Границы: 10-common vs Lite vs Bundled
-
-| Слой | Что это | Статус |
-|------|---------|--------|
-| **10-common** (этот док) | фундамент: все хост-значения параметризованы (env/конфиг), секреты выпускаются заново, smoke-процедура с PASS/FAIL | ✅ ORCH-101 |
-| **Type A — Lite** | инструкция «поставь Plane+Gitea сам, подключи оркестратор» поверх 10-common | ✅ ORCH-102 — [`docs/deployment/LITE_SETUP.md`](../deployment/LITE_SETUP.md) |
-| **Type B — Bundled** | комплект «всё в одном» (Plane+Gitea+оркестратор) поверх 10-common | ✅ ORCH-103 — [`docs/deployment/BUNDLED_SETUP.md`](../deployment/BUNDLED_SETUP.md) |
-
-Этот док НЕ описывает установку Plane/Gitea — только параметризацию, секреты и
-smoke самого оркестратора (анти-скоуп-крип Р-5).
-
-### Платформенные конвенции тиража (нормативно, ADR-001 D3/D4)
-
-- **Репо платформы обязан называться `orchestrator`.** Имя — узел безопасности
-  (`SELF_HOSTING_REPO`, на него завязаны все `*_repos`-leaf'ы «empty CSV →
-  self-hosting only»); оно сознательно НЕ конфигурируется.
-- Имена compose-сервисов/профиля (`orchestrator`, `orchestrator-staging`,
-  `orchestrator-watchdog`, профиль `staging`) — константы платформы.
-- Контейнерные пути (`/app/data`, `/repos`, `/opt/claude-code`) — layout
-  контейнера, не хост-значения; не параметризуются.
-
----
-
-## 2. Карта переменных нового хоста
-
-Принцип (ADR-001 D1): **дефолт каждой переменной = боевое значение текущего
-хоста** — пустой `.env` ⇒ поведение байт-в-байт; на новом хосте задаёшь только
-то, что отличается. Одно env-имя = один факт: pydantic `Settings` читает имя из
-`env_file`, compose-интерполяция `${VAR:-default}` — из **`.env` проекта/shell**
-(⚠️ НЕ из `env_file` сервиса: `.env.staging` на интерполяцию не влияет —
-значения для маунтов/uid/портов живут в `.env`).
-
-### 2.1. Хост-параметризация (новое в ORCH-101)
-
-| Переменная | Дефолт | Назначение |
-|-----------|--------|------------|
-| `ORCH_AGENT_HOME_DIR` | `/home/slin` | HOME всех акторов (агенты, finalizer, monitor) + таргет маунтов `.claude`/`.claude.json`/`.ssh` + `ARG APP_HOME` (группа ORCH-040 двигается вместе) |
-| `ORCH_AGENT_GIT_NAME` | `claude-bot` | git-имя коммитов агентов |
-| `ORCH_GIT_EMAIL_DOMAIN` | `mva154.local` | домен git-email всех акторов (`claude-bot@…`, `deploy-finalizer@…`, `post-deploy-monitor@…`) |
-| `ORCH_STAGING_PORT` | `8501` | порт staging; читают `image_freshness` И compose `command:`; guard: совпадение с прод-портом → отказ fail-closed (ORCH-058 AC-9) |
-| `ORCH_HOST_REPOS_DIR` | `/home/slin/repos` | каталог репозиториев на хосте (источник маунта `/repos`) |
-| `ORCH_HOST_CLAUDE_DIR` | `/home/slin/.claude` | источник маунта `~/.claude` |
-| `ORCH_HOST_CLAUDE_JSON` | `/home/slin/.claude.json` | источник маунта `~/.claude.json` |
-| `ORCH_HOST_SSH_DIR` | `/home/slin/.orchestrator-ssh` | источник маунта ssh-ключей (`→ $HOME/.ssh:ro`) |
-| `ORCH_HOST_CLAUDE_CODE_DIR` | `/usr/lib/node_modules/@anthropic-ai/claude-code` | дистрибутив claude-code на хосте |
-| `ORCH_HOST_NODE_BIN` | `/usr/bin/node` | бинарь node на хосте |
-| `ORCH_RUN_UID` / `ORCH_RUN_GID` | `1000` / `1000` | uid:gid контейнера (`user:` + `ARG APP_UID/APP_GID`); = uid владельца `ORCH_HOST_REPOS_DIR` (ORCH-040) |
-| `ORCH_DOCKER_GID` | `999` | gid группы docker хоста (`group_add`, «МИНА 1» — обязателен для docker.sock); узнать: `getent group docker` |
-| `ORCH_DEPLOY_PROD_TARGET_PORT` | `8500` | (реюз) прод-порт; интерполируется в `command:` прод-сервиса |
-| `ORCH_DEPLOY_SSH_USER` / `ORCH_DEPLOY_HOST_REPO_PATH` | `slin` / `/home/slin/repos/orchestrator` | (реюз) ssh-юзер хука и чекаут платформы на хосте; `REPO=` передаётся хуку явно из конфига |
-
-### 2.2. Обязательные ключи идентичности нового хоста
-
-| Переменная | Где взять |
-|-----------|-----------|
-| `ORCH_PLANE_API_URL` / `ORCH_PLANE_WEB_URL` / `ORCH_PLANE_WORKSPACE_SLUG` | инсталляция Plane целевого хоста |
-| `ORCH_GITEA_URL` / `ORCH_GITEA_PUBLIC_URL` / `ORCH_GITEA_OWNER` | инсталляция Gitea целевого хоста |
-| `ORCH_PROJECTS_JSON` | **обязателен на новом хосте**: встроенный fallback (`src/projects.py`) несёт Plane-UUID *исходного* хоста — чужие UUID безвредны (не сматчатся), но без своего реестра конвейер не увидит проекты. Сгенерировать: `scripts/onboard_project.py apply` печатает merged-значение |
-| Когерентность портов | сменил прод-порт → синхронно `ORCH_DEPLOY_PROD_TARGET_PORT` ⇄ `WATCHDOG_METRICS_URL` ⇄ `ORCH_POST_DEPLOY_BASE_URL` |
-
-Полный справочник всех остальных флагов — `.env.example` (канон) и
-`docs/operations/INFRA.md` (карта env).
-
----
-
-## 3. Секреты нового хоста (FR-4 / AC-5)
-
-**Нормативно: боевые секреты текущего хоста НЕ копируются ни на одном шаге.**
-Для нового хоста всегда выпускается новый комплект.
-
-### 3.1. Генерация локальных webhook-секретов
-
-```bash
-python3 scripts/gen_secrets.py            # печать .env-фрагмента в stdout
-python3 scripts/gen_secrets.py --write    # создать .env (существующий → отказ exit=2)
-python3 scripts/gen_secrets.py --write --force  # перезапись только явно
-```
-
-Скрипт stdlib-only (`secrets.token_hex(32)` — 32 байта энтропии); повторный
-запуск даёт другие значения; существующий `.env` **никогда не перезаписывается
-молча**.
-
-| Секрет | Генерируется | Куда вписать |
-|--------|--------------|--------------|
-| `ORCH_PLANE_WEBHOOK_SECRET` | локально (gen_secrets) | `.env` + настройка webhook в Plane (см. `SETUP_WEBHOOKS.md`) |
-| `ORCH_GITEA_WEBHOOK_SECRET` | локально (gen_secrets) | `.env` + webhook Gitea (создаёт `onboard_project.py apply`) |
-
-### 3.2. Чек-лист внешних токенов
-
-| Секрет | Где выпустить | Куда вписать | Как проверить |
-|--------|---------------|--------------|---------------|
-| `ORCH_PLANE_API_TOKEN` | Plane UI → Workspace Settings → API tokens | `.env` | `curl -H "X-API-Key: $TOKEN" $ORCH_PLANE_API_URL/api/v1/workspaces/<slug>/projects/` → 200 |
-| `ORCH_PLANE_BOT_*` (7, опциональны) | Plane UI: bot-аккаунты per-агент; пусто → fallback на `ORCH_PLANE_API_TOKEN` | `.env` | комментарий в Plane от имени бота |
-| `ORCH_GITEA_TOKEN` | Gitea UI → Settings → Applications → Generate Token (scope: repo, admin:repo_hook) | `.env` | `curl -H "Authorization: token $TOKEN" $ORCH_GITEA_URL/api/v1/user` → 200 |
-| `ORCH_TELEGRAM_BOT_TOKEN` | BotFather (`/newbot`) | `.env` | `curl https://api.telegram.org/bot$TOKEN/getMe` → ok |
-| `ORCH_TELEGRAM_CHAT_ID` (несекретный) | id чата оператора | `.env` | тестовое сообщение |
-| `WATCHDOG_TG_BOT_TOKEN` / `WATCHDOG_TG_CHAT_ID` | отдельный бот sidecar-watchdog (ORCH-100, независимый канал) | `.env.watchdog` | алерт от sidecar |
-
-### 3.3. Полнота
-
-`.env.example` — канон 100% ключей старта (секретные значения — только
-плейсхолдеры). Состав вывода `gen_secrets.py` сверяется с `.env.example`
-тестом (`tests/test_secrets_gen.py`).
-
----
-
-## 4. Smoke-верификация тиража (FR-5 / AC-3)
-
-Процедура «инстанс → тестовый проект → тестовая задача → конвейер доехал» из
-существующих кирпичей; **каждый шаг имеет явный PASS/FAIL**. Итог — однозначный
-вердикт: все шаги PASS ⇒ тираж PASS; любой шаг FAIL ⇒ тираж FAIL (собери логи
-контейнера `docker logs orchestrator` и снапшот `GET /queue` и разбирайся).
-
-Воспроизводимость без нового железа: процедура прогоняется на текущей инфре —
-staging-песочница (порт `ORCH_STAGING_PORT`, дефолт 8501) + sandbox-проект.
-Stateless: ни один шаг не предполагает перенос данных/БД/секретов.
-
-| # | Шаг | Команда | PASS | FAIL |
-|---|-----|---------|------|------|
-| 0 | Конфиг резолвится | `docker compose config` | резолв без ошибок; при пустом env значения = боевым дефолтам | ошибка интерполяции / неожиданные значения |
-| 1 | Инстанс жив | `curl -fsS http://127.0.0.1:<port>/health` | HTTP 200, `"status":"ok"` | не-200 / таймаут |
-| 2 | Контракты отвечают | `curl -fsS …/queue` и `…/metrics` | JSON со штатными блоками; `/metrics` → `schema_version: 1` | не-JSON / 5xx |
-| 3 | Тестовый проект | `python3 scripts/onboard_project.py plan` → `apply` → `verify` (sandbox) | `verify` зелёный (статусы/лейблы/repo/webhook на месте) | `verify` красный / manual-step не выполнен |
-| 4 | Тестовая задача | создать issue в Plane → статус «To Analyse» | задача в БД, analyst-job виден в `GET /queue` | задача не появилась (webhook/секрет/реестр) |
-| 5 | **Минимальный сигнал «конвейер доехал»** | дождаться окончания `analysis` | артефакты `01`–`04` в ветке задачи: `git ls-tree origin/<branch> docs/work-items/<id>/` | стадия не завершилась / артефактов нет |
-| 6 | Расширенный режим (опционально) | Approved → … → Confirm Deploy | задача дошла до `done` | застряла (разбор по `GET /queue` + логам) |
-
-> Ручной запуск deploy-хука на нестандартных портах — всегда с явными
-> `REPO=`/`TARGET_PORT=` (wired-путь оркестратора передаёт их сам из конфига;
-> дефолты хука — staging текущего хоста).
-
----
-
-## 5. Что НЕ переносится (stateless, решение 10.06)
-
-- БД (`data/orchestrator.db`) — создаётся пустой при первом старте;
-- `.env` / `.env.staging` / `.env.watchdog` — собираются заново (§2–§3);
-- worktree'ы/runs/логи — рабочее состояние, не данные;
-- боевые секреты — никогда (§3).
-
----
-
-*RUNBOOK ORCH-101. Поддерживать при добавлении хост-переменных (карта §2 +
-`.env.example` + INFRA.md в том же PR). Анти-регресс возврата хардкодов —
-`tests/test_no_host_hardcodes.py`; параметризация инфра-файлов —
-`tests/test_infra_parametrization.py`.*

docs/operations/SETUP_WEBHOOKS.md

@@ -12,36 +12,30 @@ Internal URL: `http://127.0.0.1:8500/`
 
 ---
 
-## Gitea Webhook (per-repo)
+## Gitea Webhook
 
-Gitea-webhook — **per-repo**: создаётся для КАЖДОГО подключаемого к оркестратору репозитория
-(`<repo>` ниже). Для новых проектов его создаёт onboarding-CLI
-(`scripts/onboard_project.py apply`) — полный процесс см. `docs/operations/ONBOARDING.md`;
-команды ниже — для ручной проверки/пересоздания на любом репо.
+**Создан автоматически через API.**
 
 - URL: `https://openclaw.mva154.duckdns.org/orchestrator/webhook/gitea`
 - Events: `push`, `pull_request`, `status`
-- Secret: значение `ORCH_GITEA_WEBHOOK_SECRET` в `.env` — **ОДИН глобальный секрет на все
-  репо** (приёмник валидирует только его; новый секрет на одном репо сломал бы HMAC остальных —
-  при ротации меняется на всех репо разом)
+- Secret: значение `ORCH_GITEA_WEBHOOK_SECRET` в `.env`
 - Signature header: `X-Gitea-Signature` (HMAC-SHA256 hex digest)
 
 ### Проверка
 
 ```bash
 GITEA_TOKEN=$(grep ORCH_GITEA_TOKEN /home/slin/repos/orchestrator/.env | cut -d= -f2)
-curl -s "http://localhost:3000/api/v1/repos/<owner>/<repo>/hooks" \
+curl -s "http://localhost:3000/api/v1/repos/admin/enduro-trails/hooks" \
   -H "Authorization: token ${GITEA_TOKEN}" | python3 -m json.tool
 ```
 
 ### Пересоздание (если нужно)
 
 ```bash
-# Секрет переиспользуй из .env (ORCH_GITEA_WEBHOOK_SECRET); генерируй новый ТОЛЬКО при
-# первичной настройке/осознанной ротации (и обнови вебхуки ВСЕХ репо):
-GITEA_WEBHOOK_SECRET=$(grep ORCH_GITEA_WEBHOOK_SECRET /home/slin/repos/orchestrator/.env | cut -d= -f2)
+GITEA_WEBHOOK_SECRET=$(openssl rand -hex 20)
+# Обновить в .env: ORCH_GITEA_WEBHOOK_SECRET=<new_secret>
 
-curl -X POST "http://localhost:3000/api/v1/repos/<owner>/<repo>/hooks" \
+curl -X POST "http://localhost:3000/api/v1/repos/admin/enduro-trails/hooks" \
   -H "Authorization: token ${GITEA_TOKEN}" \
   -H "Content-Type: application/json" \
   -d '{

docs/work-items/ORCH-009/00-business-request.md

@@ -1,7 +0,0 @@
-# Business Request: Онбординг проектов в оркестратор (turnkey: Plane + репо + агенты + инфра)
-
-Work Item ID: ORCH-009
-
-## Description
-
-TBD

docs/work-items/ORCH-009/01-brd.md

@@ -1,176 +0,0 @@
----
-work_item: ORCH-009
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 01 — BRD: ORCH-009 — Онбординг проектов в оркестратор (turnkey: Plane + репо + агенты + инфра)
-
-Work Item: **ORCH-009** · Repo: **orchestrator** (self-hosting) · Стадия: analysis
-Заказчик: Слава · Домен эпика: 📈 **D5 Масштаб (D5.2)** — `docs/epics/self-evolution.md`
-
-> ⚠️ **Актуализация Владельца 10.06 принята как приоритетная над исходной постановкой 05.06.**
-> Эталон онбординга = **сам репозиторий orchestrator** (каноны ORCH-52b/c/d/e уже кодифицированы),
-> НЕ enduro-trails (устаревший пример). «Дыра: у orchestrator только deployer.md» — уже закрыта
-> (в `.openclaw/agents/` полный набор 6 промптов). Скоуп — **способность** разворачивать новый
-> проект по образцу орка одним проходом; онбординг конкретного нового заказчика — исполнение этой
-> способности, вне данной задачи.
-
----
-
-## 1. Бизнес-контекст и проблема
-
-### 1.1. Цель
-При подключении **нового** проекта к оркестратору одним проходом разворачивается всё, что нужно
-мульти-агентам для автономной работы: Plane-проект (статусы/лейблы под машинные контракты),
-Gitea-репо (+webhook), полный набор промптов агентов, структура документации по единым канонам,
-инфра-описание (INFRA.md), регистрация в реестре проектов. Агенты нового проекта **обязаны** знать,
-где лежит документация, использовать её и актуализировать.
-
-### 1.2. Проблема сегодня
-Онбординг проекта — ручная археология: шаги размазаны по докам (`SETUP_WEBHOOKS.md`,
-`INFRA.md`), памяти Стрима/Славы и инцидентам (прецедент 2026-06-02: webhook всего workspace +
-захардкоженный `default_repo` → задачи чужого проекта падали в enduro-trails; закрыто реестром
-ORCH-6). Любой пропущенный шаг даёт **тихую деградацию**: без промптов в репо конвейер проекта не
-работает вовсе; без точных имён статусов Plane ветки `Confirm Deploy`/`STOP` молча не активируются
-(fail-closed); без лейблов авто-режимы и багфикс-трек молча выключены (fail-safe). Турникей-проход
-обязан закрывать все слои сразу и проверяемо.
-
-### 1.3. Установленные факты (проверено по коду, не изобретать)
-
-| # | Факт | Где проверено |
-|---|------|---------------|
-| Ф-1 | Промпты агентов — **per-repo**: launcher резолвит `system_prompt: .openclaw/agents/<role>.md` относительно worktree репо задачи. Нет промптов в новом репо → конвейер для него не работает. | `src/agents/launcher.py` (реестр AGENTS, 6 ролей) |
-| Ф-2 | Агент видит **только** worktree своего репо → каноны (шаблоны/стандарты) обязаны быть **скопированы** в новый репо; «ссылка на репо орка» агенту недоступна. | модель worktree `src/git_worktree.py`, launcher |
-| Ф-3 | Реестр проектов строится **при импорте** из `ORCH_PROJECTS_JSON` (или built-in default): ключи `plane_project_id`/`repo`/`work_item_prefix`/`name` + опц. `agent_models`/`agent_efforts`. Регистрация нового проекта = правка `.env` на хосте + **управляемый рестарт** (операторский шаг). | `src/projects.py` (`_parse_projects_json`, `_load_projects`) |
-| Ф-4 | Статусы Plane резолвятся по **точным именам** (22 ключа `_PLANE_NAME_TO_KEY`); `Confirm Deploy` (ORCH-059) и `STOP` (группа `cancelled`, ORCH-090) — **fail-closed** (нет статуса на доске → ветка не активируется); TTL-self-heal 300с (ORCH-068) — статус, добавленный позже, подхватывается без рестарта. | `src/plane_sync.py` (`_PLANE_NAME_TO_KEY`, `get_project_states`) |
-| Ф-5 | Лейблы `autoApprove`/`autoDeploy` (ORCH-089) и `Bug` (ORCH-019) — **fail-safe** (нет лейбла → ручной режим / полный цикл); сопоставление по нормализованному имени через Plane API. | `src/labels.py`, `src/bug_fast_track.py`, CLAUDE.md (инфра-предусловия) |
-| Ф-6 | Plane-webhook — **workspace-level** (один на все проекты, уже существует; в Plane CE создаётся SQL-ом, внешнего API нет). Gitea-webhook — **per-repo** (создаётся через API; events `push`/`pull_request`/`status`; HMAC-secret). | `docs/operations/SETUP_WEBHOOKS.md`, docstring `src/projects.py` |
-| Ф-7 | Каноны (golden source) в репо орка: `docs/_templates/` — 16 скелетов (`00…18`, ORCH-52b); `docs/_standards/` — `HANDOFF_PROTOCOL.md`/`PIPELINE_DOCS.md`/`TRACEABILITY.md` (ORCH-52c/e); `.openclaw/agents/*.md` — 6 промптов канона Anthropic (ORCH-52d/92; `deployer.md` — английский **нормативно**, ADR-001 D2 ORCH-092); ADR-конвенция — `PIPELINE_DOCS.md` §4. | листинг репо, `docs/_standards/PIPELINE_DOCS.md` |
-| Ф-8 | Per-repo паспорт `CLAUDE.md` — канон самого ORCH-9 (подпись в паспорте орка: «канон per-repo, см. ORCH-9»); все 6 промптов орка начинаются с «прочти CLAUDE.md». | `CLAUDE.md`, `.openclaw/agents/*.md` |
-
-### 1.4. Принятая трактовка постановки (расхождения 05.06 ↔ 10.06)
-- **Реализация в репо orchestrator** (данный конвейер пишет в этот репо; каноны живут здесь).
-  Упоминание отдельного репо `onboard2orch` (05.06) — историческое: его пример enduro-trails
-  объявлен устаревшим; судьба репо — операторское решение вне кода (рекомендация: архивировать/
-  оставить указатель, чтобы не плодить второй источник канона). Эскалации не требует: актуализация
-  10.06 прямо говорит «каноны кодифицированы в репо орка — их и брать за образец».
-- **Раскладка docs/**: слой-1 постановки (05.06) указывал `docs/adr/`; канон орка —
-  `docs/architecture/adr/` (сквозные) + `docs/work-items/<id>/06-adr/` (per-task). Применяется
-  канон орка (эталон = орк).
-
----
-
-## 2. Объём (scope)
-
-### 2.1. В объёме
-- **Onboarding-kit**: параметризуемый каркас нового репо — 6 промптов агентов, паспорт
-  `CLAUDE.md`, `AGENTS.md`, `CONTRIBUTING.md`, `README.md`, `CHANGELOG.md`, скелет `docs/`
-  (включая `operations/INFRA.md`), копии `docs/_templates/` + `docs/_standards/`.
-- **Onboarding-скрипт** (операторский CLI, вне конвейера): Gitea-репо + per-repo webhook,
-  Plane-проект + статусы + лейблы (в мере, доступной API), материализация kit (подстановка
-  параметров) + initial push в свежесозданный репо, генерация валидной записи реестра, режимы
-  dry-run / apply / verify, идемпотентность.
-- **Runbook** `docs/operations/ONBOARDING.md`: полный чеклист, явная маркировка ручных шагов
-  (env + управляемый рестарт; UI-only действия Plane), верификация, откат.
-- **Верификация способности**: автоматические структурные тесты kit (pytest) + документированный
-  smoke-прогон на песочнице («агент по своему промпту находит доку, использует и актуализирует»).
-- **Актуализация обзорных доков** в том же PR (CLAUDE.md, `docs/architecture/README.md`,
-  CHANGELOG, обобщение `SETUP_WEBHOOKS.md`).
-
-### 2.2. Вне объёма (явно, не делать)
-- Исполнение онбординга конкретного нового заказчика/проекта (включая правку прод-`.env` и
-  рестарт прода) — операторская эксплуатация способности.
-- ORCH-10 — тиражирование платформы на новый хост (IaC-bundle); мультитенантность (D5.6);
-  параллелизм D5.1.
-- Стеки-плагины D4.1 (профили web/mobile/data/ML): kit параметризуется плейсхолдерами, без
-  механизма профилей.
-- Любые изменения `src/**`: машина стадий, QG, launcher, реестр `projects.py` (его контракт уже
-  достаточен — регистрация через `ORCH_PROJECTS_JSON`), схема БД.
-- Создание/миграция Plane workspace-webhook (уже существует, общий на workspace).
-- Слой-3 продуктовый мониторинг онбордируемого приложения (фундамент эпика, отдельные задачи).
-
----
-
-## 3. Заинтересованные стороны
-- **Владелец/оператор (Слава, Стрим):** запускает онбординг, выполняет операторские шаги
-  (env, рестарт, UI-шаги Plane), принимает результат smoke-прогона.
-- **Будущие заказчики/проекты:** получают рабочий автономный конвейер «за минуты» (D5.2).
-- **Действующие проекты (enduro-trails, orchestrator):** не должны почувствовать онбординг
-  соседа — общий прод-инстанс, общая БД, общая очередь (self-hosting, ORCH-1).
-- **Агенты конвейера:** потребители kit — промпты обязаны вести их к доке проекта.
-
----
-
-## 4. Бизнес-требования (BR)
-
-| ID | Требование | Связь |
-|----|------------|-------|
-| BR-1 | **Turnkey-проход:** один документированный проход (скрипт + runbook) разворачивает все слои: Plane-проект (статусы+лейблы) → Gitea-репо (+webhook) → kit в репо (initial push) → запись реестра → верификация. Список шагов закрыт и воспроизводим. | AC-1, AC-11 |
-| BR-2 | **Единый эталон без форка:** kit производится от **живых** канонов репо орка — `docs/_templates/`/`docs/_standards/` копируются в новый репо в момент онбординга «как есть»; параметризация — только в kit-собственных шаблонах (промпты, паспорт, INFRA и пр.). Вторая редактируемая копия канона внутри орка не создаётся. enduro-trails эталоном не является. | AC-5, Ф-2/Ф-7 |
-| BR-3 | **Полный набор промптов:** 6 ролей (analyst/architect/developer/reviewer/tester/deployer), параметризуемых под проект/стек, по канону Anthropic 52d: 5 XML-секций в нормативном порядке, запреты «❌ X → ✅ Y», `<escalation>` у developer/reviewer/tester (ORCH-092), добровольная эмиссия 6-польной frontmatter-схемы 52c, machine-verdict ключи байт-в-байт (`verdict:`/`result:`/`staging_status:`/`deploy_status:`/`security_status:`). Каждый промпт жёстко направляет: читай паспорт/`AGENTS.md`/доку ПЕРЕД работой, пиши артефакты в `docs/work-items/<id>/` по канону, обновляй CHANGELOG/доку. | AC-2, AC-4 |
-| BR-4 | **Reviewer-gate на доку:** шаблон reviewer-промпта содержит проверку «документация обновлена; нет → REQUEST_CHANGES» (канон держится автоматически, не на честном слове). | AC-3 |
-| BR-5 | **Каркас репо полон:** `README.md`, `CHANGELOG.md`, `CONTRIBUTING.md`, `AGENTS.md` (точка входа агентов: карта доков + правила), паспорт `CLAUDE.md`, `docs/` (архитектура, конвейер, продукт-видение, `operations/`, ADR-реестр, `work-items/`, `history/`), копии `_templates/`+`_standards/`. Ссылочная целостность: промпты ссылаются только на реально существующие в каркасе пути. | AC-1, AC-5 |
-| BR-6 | **INFRA.md обязателен:** топология (контейнеры/порты прод+staging/сеть/тома/БД), карта env-переменных (дескрипторы в репо, секреты только в `.env` на хосте, `.env.example` — канон), границы доступа, риски общего хоста. Для самого орка существующие self-hosting-предупреждения (общая БД/очередь/groupwide-риск рестарта) сохраняются нетронутыми. | AC-10 |
-| BR-7 | **Plane-проект под машинные контракты:** статусы с **точными** каноническими именами (все 22 имени `_PLANE_NAME_TO_KEY`, включая `Confirm Deploy` и `STOP` с группой `cancelled`) + лейблы `autoApprove`/`autoDeploy`/`Bug`. Что недоступно через Plane API — явный ручной пункт runbook с командой проверки. | AC-7, Ф-4/Ф-5 |
-| BR-8 | **Регистрация в реестре:** скрипт генерирует запись `ORCH_PROJECTS_JSON`, валидную через фактический парсер `projects._parse_projects_json` (round-trip). Применение env + рестарт — **операторский** шаг, явно описанный в runbook; скрипт прод-контейнер НЕ рестартит. | AC-6, AC-9, Ф-3 |
-| BR-9 | **Безопасность исполнения:** dry-run по умолчанию / явный apply; идемпотентный повторный прогон (доделывает недостающее, не дублирует, ничего не удаляет); аддитивность — существующие проекты/репо не модифицируются; push — только initial в свежесозданный пустой репо (никогда в `main` существующих). | AC-8, AC-9 |
-| BR-10 | **Верификация способности:** (а) автоматические структурные тесты kit/скрипта (pytest, без сети); (б) verify-режим: registry-валидность, резолв статусов, наличие webhook, полнота kit; (в) документированный smoke на песочнице: новый агент по своему промпту находит доку, использует и актуализирует её. | AC-12, AC-13 |
-| BR-11 | **Прозрачность:** каждый шаг скрипта логируется; итоговый отчёт «создано / уже было (пропущено) / требует ручного шага». | AC-8 |
-
----
-
-## 5. Нефункциональные требования (NFR)
-
-| ID | Требование |
-|----|------------|
-| NFR-1 | **`src/**` не меняется.** Изменение — docs/templates/scripts/tests-only. `STAGE_TRANSITIONS`, реестр `QG_CHECKS`, `check_*`, machine-verdict ключи, схема БД, контракт `projects.py` — байт-в-байт. |
-| NFR-2 | **Self-hosting безопасность:** скрипт никогда не рестартит/не останавливает прод-контейнер, не пишет в общую БД, не пушит в `main` существующих репо, не трогает чужие Plane-проекты/Gitea-репо. Онбординг соседа не влияет на enduro/orchestrator. |
-| NFR-3 | **Секреты:** токены Plane/Gitea — только из env на хосте; сгенерированные секреты (webhook HMAC) выводятся оператору для `.env` и в гит не попадают; `.env.example` — канон. |
-| NFR-4 | **Anti-drift:** структурные тесты канона для kit-промптов (аналог `tests/test_agent_prompts_canon.py`) — расхождение kit с каноном 52d ловится CI, а не глазами. |
-| NFR-5 | **Оффлайн-тестируемость:** все тесты детерминированы, без реальных вызовов Plane/Gitea (моки); сетевые шаги изолированы за тонким слоем. |
-| NFR-6 | **Документация = golden source:** CLAUDE.md / `docs/architecture/README.md` / CHANGELOG обновлены в том же PR; reviewer-gate применим к самому PR. |
-
----
-
-## 6. Допущения и ограничения
-- Plane API v1 позволяет создавать проект/статусы/лейблы (issue-API уже используется кодом);
-  если на практике какой-то вызов недоступен в CE — шаг деградирует в ручной пункт runbook
-  (fail-safe постановки, не блокер задачи).
-- Скрипт — операторский инструмент: запускается человеком на хосте с токенами из `.env`,
-  **вне** конвейера задач; конвейер его не вызывает.
-- Регистрация проекта вступает в силу после операторского рестарта (Ф-3) — это сознательное
-  ограничение (никакой автоматики рестартов, NFR-2); TTL-self-heal статусов (Ф-4) рестарта
-  не требует.
-- Песочница для smoke — staging-контур (8501, изолированная БД, sandbox-проект) либо одноразовый
-  sandbox-проект в Plane/Gitea; выбор фиксирует архитектор/оператор в runbook.
-- Языковая политика kit-промптов: по канону орка (5 ru + deployer en, ADR-001 D2 ORCH-092);
-  окончательное слово за архитектором, отступление — только с обоснованием в ADR.
-
----
-
-## 7. Критерии успеха (резюме; детали — 03-acceptance-criteria.md)
-- Kit полон и канон-чист (структурные тесты зелёные): 6 промптов 52d + reviewer-gate + каркас
-  репо + INFRA.md + копии канонов.
-- Скрипт: dry-run печатает полный план без мутаций; apply идемпотентен; registry-запись проходит
-  round-trip через фактический парсер; план Plane содержит точные имена статусов и лейблы.
-- Runbook закрывает 100% шагов (ручные — помечены) и верификацию.
-- `src/**` не тронут; пайплайн-инварианты байт-в-байт.
-- Smoke на песочнице: агент по промпту находит и актуализирует доку (документированный прогон).
-
----
-
-## 8. Риски (кратко; детали — 10-tech-risks.md, заполняет архитектор)
-- **R-1 Drift канона:** копия канонов в kit/новых репо разъезжается с живым каноном орка →
-  митигируется BR-2 (live-copy в момент онбординга) + NFR-4 (структурные тесты).
-- **R-2 Тихая деградация Plane-контрактов:** опечатка в имени статуса/лейбла → fail-closed/
-  fail-safe ветки молча не работают → митигируется BR-7 (точные имена из кода) + verify-режимом.
-- **R-3 Скрипт с боевыми токенами:** ошибка = разрушительное действие → dry-run по умолчанию,
-  никаких delete-операций, аддитивность (BR-9).
-- **R-4 «Скрипт сделал — оператор не знает про env+restart»:** проект создан, но невидим для
-  оркестратора → runbook явно фиксирует операторские шаги + verify-режим показывает разрыв (BR-8/10).
-- **R-5 Утечка орк-специфики в kit:** новый проект получает чужие литералы (ORCH-, порты 8500/8501,
-  self-hosting-правила) → структурный тест на остаточные плейсхолдеры/литералы (AC-5).

docs/work-items/ORCH-009/02-trz.md

@@ -1,227 +0,0 @@
----
-work_item: ORCH-009
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 02 — ТЗ (TRZ): ORCH-009 — Онбординг проектов в оркестратор (turnkey)
-
-Work Item: **ORCH-009** · Repo: **orchestrator** · Стадия: analysis
-
-> ТЗ описывает **что** должно измениться и **где** (модули/контракты/артефакты). **Как** (точная
-> раскладка kit, механизм подстановки, формат CLI) — решает архитектор в `06-adr/`. Имена путей
-> ниже — рабочее предложение; архитектор вправе скорректировать, сохранив требования и AC.
-
-> ⚠️ Скоуп по актуализации 10.06: эталон = репо orchestrator; deliverables — в этом репо.
-> `src/**` НЕ меняется (NFR-1) — задача docs/templates/scripts/tests-only.
-
----
-
-## 1. Сводка изменения
-Создать **способность turnkey-онбординга** нового проекта: (1) параметризуемый **onboarding-kit**
-(каркас нового репо: 6 промптов агентов по канону 52d/92, паспорт, AGENTS/CONTRIBUTING, скелет
-`docs/` с INFRA.md, копии живых канонов `_templates/`+`_standards/`); (2) операторский
-**onboarding-скрипт** (Gitea-репо + per-repo webhook; Plane-проект + статусы + лейблы;
-материализация kit + initial push; генерация записи реестра; dry-run/apply/verify; идемпотентно);
-(3) **runbook** `docs/operations/ONBOARDING.md` (полный чеклист, ручные шаги, верификация);
-(4) **структурные тесты** анти-дрейфа. Конвейер/движок не трогаются.
-
----
-
-## 2. Задействованные модули / пути
-
-| Путь | Действие | Роль |
-|------|----------|------|
-| `onboarding/repo-skeleton/**` | создать | параметризуемый kit нового репо (дерево зеркалит целевой репо: `.openclaw/agents/*.md`, `CLAUDE.md`, `AGENTS.md`, `CONTRIBUTING.md`, `README.md`, `CHANGELOG.md`, `docs/**`) |
-| `onboarding/README.md` | создать | устройство kit: словарь плейсхолдеров, правило «канон не форкается» (что копируется live, что шаблонизируется) |
-| `scripts/onboard_project.py` | создать | операторский turnkey-CLI: `plan` (dry-run, дефолт) / `apply` / `verify`; идемпотентность; отчёт |
-| `docs/operations/ONBOARDING.md` | создать | runbook: последовательность, ручные шаги (env+рестарт, UI-only Plane), верификация, откат |
-| `docs/operations/SETUP_WEBHOOKS.md` | обновить | обобщить per-repo Gitea-webhook секцию (сейчас примеры захардкожены на enduro-trails); сослаться на ONBOARDING.md |
-| `tests/test_onboarding_kit.py` | создать | структура kit, канон промптов, reviewer-gate, INFRA/AGENTS/CONTRIBUTING |
-| `tests/test_onboarding_script.py` | создать | рендер/плейсхолдеры, registry round-trip, dry-run/идемпотентность, план Plane/Gitea (моки) |
-| `tests/test_onboarding_invariants.py` | создать | `src/**` не тронут логикой онбординга; снапшот `STAGE_TRANSITIONS`/`QG_CHECKS` |
-| `CLAUDE.md`, `docs/architecture/README.md`, `CHANGELOG.md` | обновить | golden source: раздел «Онбординг проектов (ORCH-009)», запись changelog |
-| `src/**` | **не менять** | NFR-1; скрипту разрешён **read-only import** `src.projects._parse_projects_json` / констант `src.plane_sync._PLANE_NAME_TO_KEY` для round-trip и точных имён (не дублировать литералы) — допустимость импорта vs снапшот-фикстура решает архитектор |
-
-Справочные источники kit (read-only): `.openclaw/agents/*.md`, `docs/_templates/` (16 скелетов),
-`docs/_standards/` (3 стандарта), `docs/operations/INFRA.md` (образец структуры RUNBOOK).
-
----
-
-## 3. Функциональные требования
-
-### FR-1 — Onboarding-kit: состав каркаса нового репо (BR-3/BR-5/BR-6)
-`onboarding/repo-skeleton/` содержит (минимум):
-
-```
-.openclaw/agents/{analyst,architect,developer,reviewer,tester,deployer}.md   ← шаблоны промптов
-CLAUDE.md            ← паспорт проекта (per-repo канон, Ф-8)
-AGENTS.md            ← точка входа агентов: карта доков + правила ведения
-CONTRIBUTING.md      ← канон процесса: где что лежит, как вести
-README.md            ← entrypoint: что это, quickstart, ссылки
-CHANGELOG.md         ← пустой каркас
-docs/ARCHITECTURE.md         ← код-карта/потоки/БД (заполняется по мере жизни)
-docs/PIPELINE.md             ← стадии, QG, агенты (ссылается на _standards)
-docs/PRODUCT_VISION.md       ← зачем проект (BRD-свод)
-docs/operations/INFRA.md     ← обязательный RUNBOOK (см. FR-3)
-docs/architecture/adr/       ← реестр сквозных ADR (канон орка, §1.4 BRD)
-docs/work-items/.gitkeep
-docs/history/.gitkeep
-docs/_templates/   ← live-копия канона орка в момент онбординга (BR-2)
-docs/_standards/   ← live-копия канона орка в момент онбординга (BR-2)
-.env.example       ← заготовка карты env (без секретов)
-```
-
-- **Параметризация** — единый словарь плейсхолдеров (минимум): `{{PROJECT_NAME}}`, `{{REPO}}`,
-  `{{WORK_ITEM_PREFIX}}`, `{{PLANE_PROJECT_ID}}`, `{{STACK}}`, `{{TEST_CMD}}`,
-  `{{PROD_PORT}}`/`{{STAGING_PORT}}` (расширяемо; единый синтаксис, фиксирует архитектор).
-- **Ссылочная целостность:** каждый путь, на который ссылаются kit-промпты/AGENTS.md, существует
-  в каркасе (проверяемо тестом).
-- **Правило «канон не форкается» (BR-2):** `docs/_templates/` и `docs/_standards/` НЕ хранятся
-  второй редактируемой копией в kit — копируются скриптом из живого канона репо орка в момент
-  материализации. В kit хранятся только параметризуемые дельты (промпты, паспорт, AGENTS,
-  CONTRIBUTING, README, INFRA и пр.).
-
-### FR-2 — Шаблоны промптов 6 ролей по канону 52d/92 (BR-3/BR-4)
-Каждый из 6 шаблонов промптов:
-- 5 обязательных XML-секций в нормативном порядке `<context>` → `<task>` → `<deliverables>` →
-  `<constraints>` → `<output_format>`; `<success_criteria>`; `<escalation>` у
-  developer/reviewer/tester (после `</success_criteria>`); `<thinking>` у решающих ролей —
-  как в эталоне `.openclaw/agents/` (ORCH-077/092).
-- Запреты в формате «❌ X → ✅ Y».
-- Директивы доки (жёстко): читай `CLAUDE.md`(паспорт)/`AGENTS.md`/`docs/ARCHITECTURE.md`/ADR
-  ПЕРЕД работой; пиши артефакты в `docs/work-items/<id>/` по `docs/_standards/PIPELINE_DOCS.md`
-  (скелеты из `docs/_templates/`); архитектор фиксирует решения в `06-adr/` + сквозные в
-  `docs/architecture/adr/adr-NNNN-slug.md`; каждый обновляет `CHANGELOG.md`/релевантную доку.
-- **Reviewer:** содержит gate «документация обновлена? нет → `verdict: REQUEST_CHANGES`».
-- Эмиссия 6-польной frontmatter-схемы 52c (`work_item`/`stage`/`author_agent`/`status`/
-  `created_at`/`model_used`) — аддитивно; machine-verdict ключи и значения байт-в-байт
-  (`verdict:`/`result:`/`staging_status:`/`deploy_status:`/`security_status:`); копируемые
-  примеры — с плейсхолдерами `<YYYY-MM-DD>`/`<resolve по конфигу>` (анти-паттерн ORCH-092 учтён).
-- Стек-специфика (язык/тесты/команды) — только через плейсхолдеры; никаких унаследованных
-  орк-литералов (порты 8500/8501, «ORCH-», self-hosting-правила орка) в материализованном виде.
-- Языковая политика: по канону орка (5 ru + deployer en, нормативно ADR-001 D2 ORCH-092);
-  отступление — только решением архитектора в ADR.
-
-### FR-3 — INFRA.md шаблон: обязательные секции (BR-6)
-Шаблон `docs/operations/INFRA.md` нового проекта содержит секции: топология (контейнеры, порты
-прод/staging, сеть, тома, БД); карта env-переменных (дескрипторы в репо; секреты ТОЛЬКО в `.env`
-на хосте; `.env.example` — канон; `docker-compose.yml`/`Dockerfile` трекаются в гите); границы
-доступа; эксплуатационные предупреждения, включая **риски общего хоста** (соседние контейнеры,
-общие ресурсы; факт: хост впритык — см. `docs/epics/self-evolution.md` С-3). Существующий
-`docs/operations/INFRA.md` орка с self-hosting-предупреждениями (общая БД/очередь/групповой риск
-рестарта) — не модифицируется этой задачей (read-only образец).
-
-### FR-4 — Onboarding-скрипт: провижининг (BR-1/BR-7/BR-9/BR-11)
-`scripts/onboard_project.py` (вход: имя проекта, repo, префикс work-item, параметры стека):
-- **Gitea:** создать репо (API), создать per-repo webhook (`push`/`pull_request`/`status`,
-  HMAC-secret из/для `.env` — формат `SETUP_WEBHOOKS.md`); материализовать kit → **initial push
-  в свежесозданный пустой репо** (единственный разрешённый push; в существующие репо — никогда).
-- **Plane:** создать проект (или принять существующий `--plane-project-id`); создать статусы со
-  **точными** именами из `_PLANE_NAME_TO_KEY` (22 имени; `STOP` — группа `cancelled`,
-  `Confirm Deploy` — отдельный статус; группы фиксирует архитектор по `plane_sync`) и лейблы
-  `autoApprove`/`autoDeploy`/`Bug`. Недоступное через API CE → пункт отчёта «ручной шаг» со
-  ссылкой на runbook (fail-safe, не падение).
-- **Реестр:** сгенерировать запись `ORCH_PROJECTS_JSON` (полный новый массив или диф —
-  фиксирует архитектор), **валидную через фактический `projects._parse_projects_json`**;
-  вывести оператору инструкцию «добавь в `.env` + управляемый рестарт». Скрипт сам `.env` прода
-  не правит и контейнер не рестартит (NFR-2).
-- **Режимы:** `plan` (дефолт; полный план без единой мутации), `apply` (исполнение),
-  `verify` (см. FR-5). Идемпотентность: повторный `apply` обнаруживает существующее
-  (репо/webhook/статусы/лейблы/файлы) и пропускает с пометкой; ничего не удаляет и не
-  перезаписывает существующий контент без явного флага.
-- **Прозрачность:** лог каждого шага + итоговый отчёт: `created / skipped(exists) / manual-step`.
-- **Webhook Plane:** не создаётся (workspace-level уже существует, Ф-6) — только проверка в verify.
-
-### FR-5 — Верификация (BR-10)
-- `verify`-режим скрипта: запись реестра парсится (`_parse_projects_json` round-trip → поля
-  совпадают); статусы проекта резолвятся (все логические ключи, включая `confirm_deploy`/`stop`);
-  лейблы присутствуют; Gitea-webhook существует и активен; kit-файлы в репо (включая 6 промптов,
-  AGENTS.md, INFRA.md, `_templates`/`_standards`); нет неразрешённых плейсхолдеров.
-- **Smoke на песочнице** (runbook, операторский): онбордить sandbox-проект → создать тестовую
-  задачу → стадия analysis в песочнице → убедиться: агент прочитал доку проекта (следы в
-  выводе/артефактах) и записал артефакты в `docs/work-items/<id>/` по канону. Контур песочницы
-  (staging 8501 / одноразовый sandbox) фиксирует архитектор в ADR + runbook.
-
-### FR-6 — Runbook ONBOARDING.md (BR-1/BR-8)
-Полный чеклист онбординга: предусловия (токены, доступы) → шаги скрипта → **операторские шаги**
-(env+рестарт — с предупреждением self-hosting: рестарт прода = групповое окно, выполнять
-осознанно; UI-only шаги Plane, напр. drag-and-drop порядок статусов) → верификация (verify +
-smoke) → откат (удаление созданного — вручную, скрипт не удаляет). Каждый ручной шаг — с командой
-проверки результата.
-
----
-
-## 4. Изменения API
-**Нет.** Новые/изменённые HTTP-эндпоинты оркестратора не вводятся; вебхук-контракты не меняются.
-(Onboarding-CLI — операторский инструмент вне FastAPI-приложения.)
-
-## 5. Изменения схемы БД
-**Нет.** Общая БД не читается и не пишется скриптом (NFR-2).
-
-## 6. Требования к новым/изменённым QG checks
-**Нет.** Реестр `QG_CHECKS`/`check_*`/`STAGE_TRANSITIONS` — байт-в-байт (контроль — снапшот-тест,
-TC-18). Онбординг — операторская способность, не гейт конвейера.
-
----
-
-## 7. Совместимость / регресс
-- **Нулевая регрессия кода:** `src/**` не меняется → поведение конвейера для enduro/orchestrator
-  идентично; полный регресс `tests/` остаётся зелёным.
-- **Kill-switch не требуется:** способность активируется только явным запуском операторского CLI;
-  в горячих путях конвейера нового кода нет.
-- **Обратимость:** удаление `onboarding/`/`scripts/onboard_project.py`/runbook возвращает репо в
-  исходное состояние; созданные онбордингом внешние сущности сносятся вручную по разделу
-  «Откат» runbook.
-- **Совместимость канонов:** kit-промпты проходят те же структурные требования, что эталонные
-  (анти-дрейф NFR-4); обновление канона орка автоматически подхватывается live-copy частью kit
-  (BR-2), шаблонные дельты — через обычные PR с reviewer-gate.
-
----
-
-## 8. Артефакты pipeline (создать/обновить в ТОМ ЖЕ PR)
-- `docs/work-items/ORCH-009/06-adr/ADR-001-…` — решения архитектора (раскладка kit, синтаксис
-  плейсхолдеров, copy-vs-template split по файлам, импорт `src` из скрипта vs снапшот, контур
-  песочницы, языковая политика kit-deployer).
-- `docs/architecture/README.md` — раздел «Онбординг проектов (ORCH-009)».
-- `CLAUDE.md` — краткий абзац о способности онбординга.
-- `CHANGELOG.md` — запись `feat:`.
-- `docs/operations/ONBOARDING.md` (новый), `docs/operations/SETUP_WEBHOOKS.md` (обобщение).
-- `07-infra-requirements.md` — предусловия онбординга (токены/доступы), заполняет архитектор.
-
----
-
-## 9. Инварианты (не нарушать)
-- `src/**` без изменений; `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict ключи/схема
-  БД — байт-в-байт (NFR-1).
-- Скрипт: не рестартит/не останавливает прод-контейнер; не пушит в `main` существующих репо
-  (INV-4 — мерж только через PR-merge API — не затрагивается: initial push идёт в свежесозданный
-  пустой репо, не являющийся участником конвейера до регистрации); не удаляет внешние сущности;
-  секреты в гит не попадают (NFR-2/NFR-3).
-- Никаких сетевых вызовов в тестах (NFR-5); никаких новых обязательных pip-зависимостей без
-  обоснования в ADR.
-- Эталонные промпты орка `.openclaw/agents/*.md` этой задачей не модифицируются (они — read-only
-  образец; их правка = отдельные задачи канона).
-
----
-
-## 10. Открытые вопросы для архитектора (не блокируют анализ)
-- OQ-1: Раскладка kit — `onboarding/repo-skeleton/` (предложение) vs `docs/_onboarding/` vs
-  `scripts/onboarding/`; где словарь плейсхолдеров.
-- OQ-2: Механизм подстановки — stdlib (`str.replace`/`string.Template`) без новых зависимостей
-  (рекомендация) vs шаблонизатор (новая зависимость — потребует обоснования).
-- OQ-3: Copy-vs-template split: какие файлы kit — live-copy канона, какие — параметризуемые
-  шаблоны (минимум по BR-2: `_templates`/`_standards` — live-copy).
-- OQ-4: Скрипту импортировать `src.projects`/`src.plane_sync` (точные имена/парсер, нет
-  дублирования) vs автономный снапшот констант с тестом синхронизации.
-- OQ-5: Plane API CE: фактическая доступность создания проекта/статусов/лейблов — что уходит в
-  ручные шаги runbook.
-- OQ-6: Контур песочницы для smoke (staging 8501 vs одноразовый sandbox-проект) и судьба
-  sandbox-артефактов после прогона.
-- OQ-7: Языковая политика kit-промптов для не-self-hosting проектов (рекомендация: канон орка,
-  deployer — en).
-- OQ-8: Защита `main` нового репо в Gitea (branch protection): не должна ломать PR-merge API
-  конвейера — включать ли вообще (рекомендация: не включать, зафиксировать в runbook).

docs/work-items/ORCH-009/03-acceptance-criteria.md

@@ -1,146 +0,0 @@
----
-work_item: ORCH-009
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 03 — Критерии приёмки (Acceptance Criteria): ORCH-009 — Turnkey-онбординг проектов
-
-Work Item: **ORCH-009** · Repo: **orchestrator** · Стадия: analysis
-
-Формат: каждый критерий — чёткое условие **PASS/FAIL**, проверяемое буквально по файлам
-репозитория и детерминированным тестам (без сети). AC-13 — единственный операторский
-(документированный smoke), его автоматизируемая часть вынесена в AC-2/AC-12.
-
----
-
-## AC-1 — Kit полон (состав каркаса)
-**Условие:** инспекция `onboarding/repo-skeleton/` (или каталога, выбранного архитектором в ADR).
-- **PASS:** присутствуют все элементы FR-1: 6 шаблонов промптов (`analyst/architect/developer/
-  reviewer/tester/deployer`), `CLAUDE.md`, `AGENTS.md`, `CONTRIBUTING.md`, `README.md`,
-  `CHANGELOG.md`, `docs/ARCHITECTURE.md`, `docs/PIPELINE.md`, `docs/PRODUCT_VISION.md`,
-  `docs/operations/INFRA.md`, `docs/architecture/adr/`, `docs/work-items/`, `docs/history/`,
-  `.env.example`; материализация добавляет live-копии `docs/_templates/` + `docs/_standards/`.
-- **FAIL:** отсутствует любой элемент состава, либо промптов меньше 6.
-
-## AC-2 — Промпты kit соответствуют канону 52d/92
-**Условие:** структурные тесты по каждому из 6 шаблонов промптов.
-- **PASS:** в каждом — 5 обязательных XML-секций в нормативном порядке `<context>→<task>→
-  <deliverables>→<constraints>→<output_format>`; запреты в формате «❌ → ✅»; `<escalation>` у
-  developer/reviewer/tester; директивы «читай паспорт/AGENTS.md/доку ПЕРЕД работой» и «пиши
-  артефакты в `docs/work-items/<id>/`»; эмиссия 6-польной frontmatter-схемы 52c с
-  плейсхолдерными примерами дат/моделей; machine-verdict ключи у ролей-вердиктов байт-в-байт
-  (`verdict:` / `result:` / `staging_status:` / `deploy_status:` / `security_status:`).
-- **FAIL:** нарушен порядок/состав секций, отсутствует любой verdict-ключ или директива доки,
-  пример frontmatter содержит захардкоженные дату/модель.
-
-## AC-3 — Reviewer-gate на обновление доки
-**Условие:** шаблон `reviewer.md` в kit.
-- **PASS:** содержит явное правило: документация (CHANGELOG/релевантные доки/ADR) обновлена в том
-  же PR; нет → `verdict: REQUEST_CHANGES`.
-- **FAIL:** правило отсутствует или сформулировано как необязательное.
-
-## AC-4 — Языковая политика kit
-**Условие:** проверка языка шаблонов промптов против решения ADR (дефолт — канон орка).
-- **PASS:** языковая раскладка соответствует зафиксированной в ADR (по умолчанию: 5 ru +
-  deployer en, как ADR-001 D2 ORCH-092); отступление — только с обоснованием в ADR.
-- **FAIL:** язык промптов противоречит ADR, либо политика нигде не зафиксирована.
-
-## AC-5 — Материализация: плейсхолдеры и отсутствие утечек
-**Условие:** рендер kit с тестовыми параметрами (`PROJECT_NAME`, `REPO`, `WORK_ITEM_PREFIX` и т.д.).
-- **PASS:** все плейсхолдеры подставлены; в результате нет ни одного неразрешённого плейсхолдера
-  (grep по синтаксису из ADR); нет утечек орк-специфики, где должен быть параметр (литералы
-  `ORCH-` как префикс work-item чужого проекта, порты 8500/8501, self-hosting-правила орка);
-  пути, на которые ссылаются отрендеренные промпты/AGENTS.md, существуют в каркасе.
-- **FAIL:** найден неразрешённый плейсхолдер, орк-литерал вместо параметра или битая ссылка
-  на несуществующий путь.
-
-## AC-6 — Registry round-trip через фактический парсер
-**Условие:** скрипт генерирует запись реестра для тестового проекта.
-- **PASS:** сгенерированный JSON парсится `projects._parse_projects_json` без ошибок; полученный
-  `ProjectConfig` несёт исходные `plane_project_id`/`repo`/`work_item_prefix`/`name`; существующие
-  записи реестра не модифицируются и не теряются.
-- **FAIL:** парсер отвергает запись, поля искажены, либо генерация ломает/теряет существующие записи.
-
-## AC-7 — План Plane: точные статусы и лейблы
-**Условие:** `plan`-режим для нового проекта (моки сети).
-- **PASS:** план провижининга содержит ВСЕ канонические имена статусов из `_PLANE_NAME_TO_KEY`
-  (включая `Confirm Deploy` и `STOP` с группой `cancelled`) и лейблы `autoApprove`/`autoDeploy`/
-  `Bug`; имена байт-в-байт совпадают с константами `src/plane_sync.py` (или их синхронизированным
-  снапшотом по OQ-4); недоступные через API шаги помечены `manual-step` со ссылкой на runbook.
-- **FAIL:** пропущен/искажён любой статус или лейбл; недоступный шаг молча отброшен.
-
-## AC-8 — План Gitea: репо + per-repo webhook; dry-run без мутаций
-**Условие:** `plan`-режим (моки сети).
-- **PASS:** план содержит создание репо, создание webhook с events `push`/`pull_request`/`status`
-  и HMAC-secret (секрет — для `.env` оператора, не в гит), материализацию kit + initial push в
-  свежесозданный репо; в режиме `plan` не выполняется НИ ОДНОЙ мутации (ни одного
-  POST/PUT/DELETE-вызова в моках, ни одной записи на диск вне отчёта).
-- **FAIL:** план неполон, или dry-run произвёл мутацию.
-
-## AC-9 — Идемпотентность и безопасность apply
-**Условие:** повторный `apply` на частично/полностью созданном проекте (моки: сущности существуют).
-- **PASS:** существующие сущности (репо/webhook/статусы/лейблы/файлы) распознаны и пропущены с
-  пометкой `skipped(exists)`; ничего не удалено и не перезаписано без явного флага; скрипт не
-  выполняет рестарт/останов контейнеров, не правит `.env` прода, не пушит в существующие репо
-  (в коде отсутствуют такие операции — проверяемо тестом/ревью); итоговый отчёт перечисляет
-  created/skipped/manual-step.
-- **FAIL:** дублирование сущностей, любое удаление/перезапись без флага, любая операция
-  рестарта/push в существующий репо, отсутствие отчёта.
-
-## AC-10 — INFRA.md шаблон: обязательные секции
-**Условие:** инспекция шаблона `docs/operations/INFRA.md` в kit.
-- **PASS:** присутствуют секции: топология (контейнеры/порты прод+staging/сеть/тома/БД);
-  карта env-переменных + правило секретов (только `.env` на хосте, `.env.example` — канон);
-  границы доступа; предупреждения о рисках общего хоста. Существующий `docs/operations/INFRA.md`
-  орка (self-hosting-предупреждения) этой задачей не изменён.
-- **FAIL:** отсутствует любая обязательная секция, либо изменён INFRA.md самого орка.
-
-## AC-11 — Runbook ONBOARDING.md полон
-**Условие:** инспекция `docs/operations/ONBOARDING.md`.
-- **PASS:** покрывает все слои BR-1 в последовательности: предусловия (токены/доступы) → Plane
-  (проект/статусы/лейблы) → Gitea (репо/webhook) → kit (материализация/push) → регистрация
-  (env-строка + операторский управляемый рестарт с self-hosting-предупреждением) → верификация
-  (`verify` + smoke на песочнице) → откат; каждый ручной шаг помечен и снабжён командой проверки;
-  Plane workspace-webhook описан как существующий (проверка, не создание).
-- **FAIL:** пропущен слой, ручной шаг не помечен/без проверки, или runbook требует
-  автоматического рестарта прода.
-
-## AC-12 — Инварианты: src/** не тронут
-**Условие:** diff PR + снапшот-тест.
-- **PASS:** `git diff` PR не содержит изменений `src/**`; снапшот `STAGE_TRANSITIONS` и реестра
-  `QG_CHECKS` совпадает с эталоном; эталонные промпты `.openclaw/agents/*.md` орка не изменены;
-  полный регресс `tests/` зелёный.
-- **FAIL:** любой diff в `src/**` или `.openclaw/agents/`, расхождение снапшота, красный регресс.
-
-## AC-13 — Smoke: агент находит, использует и актуализирует доку (операторский)
-**Условие:** документированный прогон по runbook на песочнице (контур — по ADR): онбординг
-sandbox-проекта → тестовая задача → стадия analysis.
-- **PASS:** агент песочницы по своему промпту прочитал доку проекта (следы чтения паспорта/
-  AGENTS.md в выводе или артефактах) и записал артефакты в `docs/work-items/<id>/` по канону
-  (структура соответствует `PIPELINE_DOCS.md`); результат прогона зафиксирован в runbook/отчёте
-  задачи. Для приёмки данной задачи прогон выполняется один раз и протоколируется.
-- **FAIL:** агент не нашёл доку (артефакты вне канона/не созданы), либо прогон не запротоколирован.
-
----
-
-## Сводная матрица AC ↔ BR/FR
-
-| AC | BR | FR | Тип проверки |
-|----|----|----|--------------|
-| AC-1 | BR-5 | FR-1 | unit (структура kit) |
-| AC-2 | BR-3 | FR-2 | unit (структурный канон) |
-| AC-3 | BR-4 | FR-2 | unit |
-| AC-4 | BR-3 | FR-2 | unit + ADR |
-| AC-5 | BR-2/BR-5 | FR-1/FR-2 | unit (рендер) |
-| AC-6 | BR-8 | FR-4 | integration (реальный парсер) |
-| AC-7 | BR-7 | FR-4 | unit (план, моки) |
-| AC-8 | BR-1/BR-9 | FR-4 | unit (план, моки) |
-| AC-9 | BR-9/BR-11 | FR-4 | unit/integration (моки) |
-| AC-10 | BR-6 | FR-3 | unit (структура) |
-| AC-11 | BR-1/BR-8 | FR-6 | unit (структура дока) |
-| AC-12 | NFR-1 | — | unit (снапшот) + ревью diff |
-| AC-13 | BR-10 | FR-5 | ручной smoke (протоколируемый) |

docs/work-items/ORCH-009/04-test-plan.yaml

@@ -1,164 +0,0 @@
-work_item: ORCH-009
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
-title: "Turnkey-онбординг проектов: kit + скрипт + runbook (ORCH-009)"
-framework: pytest
-scope: >
-  Структурная полнота onboarding-kit, канон 52d/92 шаблонов промптов, материализация
-  (плейсхолдеры/утечки), registry round-trip через фактический парсер projects.py,
-  планы Plane/Gitea (dry-run, моки), идемпотентность apply, runbook, инварианты src/**.
-  Вне покрытия pytest: реальные вызовы Plane/Gitea API и операторский smoke на песочнице
-  (AC-13) — выполняется вручную по docs/operations/ONBOARDING.md и протоколируется.
-notes: >
-  Все тесты детерминированы, без сети (Plane/Gitea мокируются; NFR-5). Точные имена файлов
-  тест-модулей могут уточняться архитектором при сохранении покрытия TC↔AC. Полный регресс
-  tests/ должен оставаться зелёным (src/** не меняется — NFR-1). Если ADR изменит раскладку
-  kit (OQ-1) — пути в тестах следуют ADR, маппинг TC↔AC неизменен.
-
-tests:
-  # ---------- AC-1: состав kit ----------
-  - id: TC-01
-    type: unit
-    description: "Kit содержит все элементы FR-1: 6 шаблонов промптов, CLAUDE.md, AGENTS.md, CONTRIBUTING.md, README.md, CHANGELOG.md, docs/ARCHITECTURE.md, docs/PIPELINE.md, docs/PRODUCT_VISION.md, docs/operations/INFRA.md, docs/architecture/adr/, docs/work-items/, docs/history/, .env.example"
-    module: tests/test_onboarding_kit.py
-    expected: PASS
-
-  - id: TC-02
-    type: unit
-    description: "Материализация добавляет live-копии docs/_templates/ (16 канонических скелетов) и docs/_standards/ (3 стандарта) из живого канона репо орка; вторая редактируемая копия канона в kit отсутствует (BR-2)"
-    module: tests/test_onboarding_script.py
-    expected: PASS
-
-  # ---------- AC-2: канон промптов 52d/92 ----------
-  - id: TC-03
-    type: unit
-    description: "Каждый из 6 шаблонов промптов содержит 5 обязательных XML-секций в нормативном порядке context→task→deliverables→constraints→output_format"
-    module: tests/test_onboarding_kit.py
-    expected: PASS
-
-  - id: TC-04
-    type: unit
-    description: "Шаблоны developer/reviewer/tester содержат секцию <escalation>; запреты оформлены в формате '❌ → ✅'"
-    module: tests/test_onboarding_kit.py
-    expected: PASS
-
-  - id: TC-05
-    type: unit
-    description: "Каждый шаблон промпта направляет агента к доке: читай паспорт(CLAUDE.md)/AGENTS.md/ARCHITECTURE/ADR перед работой; пиши артефакты в docs/work-items/<id>/ по PIPELINE_DOCS; обновляй CHANGELOG/доку"
-    module: tests/test_onboarding_kit.py
-    expected: PASS
-
-  - id: TC-06
-    type: unit
-    description: "Шаблоны эмитят 6-польную frontmatter-схему 52c (work_item/stage/author_agent/status/created_at/model_used); machine-verdict ключи ролей байт-в-байт (verdict:/result:/staging_status:/deploy_status:/security_status:); примеры дат/моделей — плейсхолдеры, не литералы (анти-паттерн ORCH-092)"
-    module: tests/test_onboarding_kit.py
-    expected: PASS
-
-  # ---------- AC-3: reviewer-gate ----------
-  - id: TC-07
-    type: unit
-    description: "Шаблон reviewer.md содержит обязательный gate: документация не обновлена в PR → verdict: REQUEST_CHANGES"
-    module: tests/test_onboarding_kit.py
-    expected: PASS
-
-  # ---------- AC-4: языковая политика ----------
-  - id: TC-08
-    type: unit
-    description: "Языковая раскладка шаблонов соответствует политике ADR (дефолт: 5 ru + deployer en, канон ADR-001 D2 ORCH-092)"
-    module: tests/test_onboarding_kit.py
-    expected: PASS
-
-  # ---------- AC-5: материализация ----------
-  - id: TC-09
-    type: unit
-    description: "Рендер kit с тестовыми параметрами подставляет все плейсхолдеры: в выходе нет ни одного неразрешённого плейсхолдера (grep по синтаксису из ADR)"
-    module: tests/test_onboarding_script.py
-    expected: PASS
-
-  - id: TC-10
-    type: unit
-    description: "В отрендеренном kit нет утечек орк-специфики, где должен быть параметр: префикс ORCH- вместо префикса проекта, порты 8500/8501, self-hosting-правила орка"
-    module: tests/test_onboarding_script.py
-    expected: PASS
-
-  - id: TC-11
-    type: unit
-    description: "Ссылочная целостность: каждый путь, на который ссылаются отрендеренные промпты и AGENTS.md, существует в материализованном каркасе"
-    module: tests/test_onboarding_script.py
-    expected: PASS
-
-  # ---------- AC-6: registry round-trip ----------
-  - id: TC-12
-    type: integration
-    description: "Сгенерированная скриптом запись реестра парсится фактическим projects._parse_projects_json; ProjectConfig несёт исходные plane_project_id/repo/work_item_prefix/name; существующие записи реестра сохранены без искажений"
-    module: tests/test_onboarding_script.py
-    expected: PASS
-
-  # ---------- AC-7: план Plane ----------
-  - id: TC-13
-    type: unit
-    description: "plan-режим: план Plane содержит все канонические имена статусов _PLANE_NAME_TO_KEY (включая 'Confirm Deploy' и 'STOP' с группой cancelled) байт-в-байт и лейблы autoApprove/autoDeploy/Bug"
-    module: tests/test_onboarding_script.py
-    expected: PASS
-
-  - id: TC-14
-    type: unit
-    description: "Шаг Plane, недоступный через API (мок отвечает отказом/не реализовано), помечается в плане/отчёте как manual-step со ссылкой на runbook — не отбрасывается молча и не валит скрипт"
-    module: tests/test_onboarding_script.py
-    expected: PASS
-
-  # ---------- AC-8: план Gitea + dry-run ----------
-  - id: TC-15
-    type: unit
-    description: "plan-режим: план Gitea содержит создание репо, webhook (events push/pull_request/status + HMAC-secret вне гита) и initial push kit в свежесозданный репо"
-    module: tests/test_onboarding_script.py
-    expected: PASS
-
-  - id: TC-16
-    type: unit
-    description: "dry-run (plan) не выполняет ни одной мутации: ноль POST/PUT/DELETE в замоканных клиентах Plane/Gitea, ноль git push, ноль записей на диск вне отчёта"
-    module: tests/test_onboarding_script.py
-    expected: PASS
-
-  # ---------- AC-9: идемпотентность / безопасность apply ----------
-  - id: TC-17
-    type: integration
-    description: "Повторный apply на уже созданном проекте (моки: репо/webhook/статусы/лейблы существуют): сущности распознаны и помечены skipped(exists); нет дублей, удалений и перезаписи без явного флага; итоговый отчёт перечисляет created/skipped/manual-step"
-    module: tests/test_onboarding_script.py
-    expected: PASS
-
-  - id: TC-18
-    type: unit
-    description: "Скрипт не содержит операций рестарта/останова контейнеров, правки прод-.env и push в существующие репо: на моках полного прогона apply такие вызовы отсутствуют (NFR-2)"
-    module: tests/test_onboarding_script.py
-    expected: PASS
-
-  # ---------- AC-10: INFRA.md шаблон ----------
-  - id: TC-19
-    type: unit
-    description: "Шаблон INFRA.md kit содержит обязательные секции: топология (контейнеры/порты прод+staging/сеть/тома/БД), карта env + правило секретов (.env на хосте, .env.example — канон), границы доступа, риски общего хоста"
-    module: tests/test_onboarding_kit.py
-    expected: PASS
-
-  # ---------- AC-11: runbook ----------
-  - id: TC-20
-    type: unit
-    description: "ONBOARDING.md покрывает все слои в последовательности: предусловия → Plane → Gitea → kit → регистрация (env + операторский управляемый рестарт с self-hosting-предупреждением) → верификация (verify + smoke) → откат; ручные шаги помечены и снабжены командами проверки"
-    module: tests/test_onboarding_kit.py
-    expected: PASS
-
-  # ---------- AC-12: инварианты ----------
-  - id: TC-21
-    type: unit
-    description: "Снапшот STAGE_TRANSITIONS и реестра QG_CHECKS совпадает с эталоном (src/** не затронут логикой онбординга); эталонные промпты .openclaw/agents/ орка не изменены задачей"
-    module: tests/test_onboarding_invariants.py
-    expected: PASS
-
-  - id: TC-22
-    type: integration
-    description: "Полный регресс существующего tests/ остаётся зелёным после добавления onboarding-артефактов (никакой новый импорт/код не ломает конвейер)"
-    module: tests/
-    expected: PASS

docs/work-items/ORCH-009/06-adr/ADR-001-turnkey-onboarding-kit-and-cli.md

@@ -1,341 +0,0 @@
----
-work_item: ORCH-009
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# ADR-001: Turnkey-онбординг проектов — kit `onboarding/` + операторский CLI + runbook
-
-Work Item: **ORCH-009** — Онбординг проектов в оркестратор (turnkey: Plane + репо + агенты + инфра)
-Стадия: **architecture**
-Связь: BRD `01-brd.md`, ТЗ `02-trz.md`, AC `03-acceptance-criteria.md`, тест-план `04-test-plan.yaml`,
-инфра `07-infra-requirements.md`, риски `10-tech-risks.md`.
-Сквозная регистрация: **`docs/architecture/adr/adr-0035-turnkey-project-onboarding.md`**
-(решение кросс-каттинговое: новая способность уровня всего оркестратора — масштабирование на
-новые проекты, домен D5.2 эпика саморазвития).
-
-## Статус
-Proposed
-
----
-
-## Контекст
-
-Онбординг нового проекта сегодня — ручная археология по `SETUP_WEBHOOKS.md`/`INFRA.md`/памяти;
-любой пропуск даёт тихую деградацию (BRD §1.2): без промптов в репо конвейер проекта не работает
-вовсе (Ф-1: launcher резолвит `.openclaw/agents/<role>.md` **относительно worktree репо задачи**);
-без точных имён статусов ветки `Confirm Deploy`/`STOP` молча не активируются (fail-closed,
-`src/plane_sync.py:130-165`); без лейблов авто-режимы/багфикс-трек молча выключены (fail-safe,
-`src/labels.py`/`src/bug_fast_track.py`).
-
-Ограничения, заданные анализом и проверенные по коду:
-
-- **NFR-1:** `src/**` не меняется; `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict
-  ключи/схема БД/контракт `projects.py` — байт-в-байт. Задача docs/templates/scripts/tests-only.
-- **Ф-2:** агент видит только worktree своего репо → каноны обязаны быть **скопированы** в новый
-  репо (ссылка на репо орка агенту недоступна).
-- **Ф-3:** реестр строится при импорте из `ORCH_PROJECTS_JSON` (`src/projects.py::_load_projects`);
-  регистрация = правка `.env` + **операторский** управляемый рестарт.
-- **Ф-6:** Plane-webhook — workspace-level, уже существует (в CE создаётся SQL-ом, внешнего API
-  нет); Gitea-webhook — per-repo, через API (`push`/`pull_request`/`status`, HMAC).
-- **Ф-7:** живой канон — `docs/_templates/` (16 скелетов), `docs/_standards/` (3 стандарта),
-  `.openclaw/agents/*.md` (канон 52d/92).
-- Эталон онбординга = **сам репозиторий orchestrator** (актуализация Владельца 10.06);
-  enduro-trails эталоном не является.
-
-ТЗ оставило архитектору 8 открытых вопросов (OQ-1…OQ-8) — все закрываются ниже (D1…D11).
-
----
-
-## Решение
-
-### Сводка
-
-Три артефакта + тесты, всё **вне конвейера и вне рантайма**:
-
-1. **Onboarding-kit** `onboarding/repo-skeleton/` — параметризуемый каркас нового репо
-   (6 промптов канона 52d/92, паспорт `CLAUDE.md`, `AGENTS.md`, `CONTRIBUTING.md`, скелет `docs/`
-   с обязательным `operations/INFRA.md`); словарь плейсхолдеров — `onboarding/placeholders.json`.
-2. **Операторский CLI** `scripts/onboard_project.py` — `plan` (дефолт, GET-only) / `apply`
-   (идемпотентный ensure) / `verify`; Plane (проект+статусы+лейблы) → Gitea (репо+webhook) →
-   материализация kit (рендер + live-copy канона) + initial push → генерация записи реестра →
-   отчёт `created/skipped(exists)/manual-step`.
-3. **Runbook** `docs/operations/ONBOARDING.md` — полный чеклист, явные ручные шаги
-   (env + управляемый рестарт; UI-only Plane), верификация (verify + smoke на staging), откат.
-
-Никакого нового кода в горячих путях; kill-switch не нужен (способность активируется только
-явным запуском CLI человеком — TRZ §7).
-
-### D1 — Раскладка: top-level `onboarding/` (OQ-1)
-
-**Решение: `onboarding/` в корне репо** — ровно как предложено ТЗ:
-
-```
-onboarding/
-  README.md            ← устройство kit: словарь плейсхолдеров, правило «канон не форкается»,
-                          copy-vs-template карта (D3), как запускать тесты kit
-  placeholders.json    ← словарь плейсхолдеров (single source of truth, D2)
-  repo-skeleton/       ← дерево зеркалит целевой репо (FR-1)
-    .openclaw/agents/{analyst,architect,developer,reviewer,tester,deployer}.md
-    CLAUDE.md  AGENTS.md  CONTRIBUTING.md  README.md  CHANGELOG.md  .env.example
-    docs/ARCHITECTURE.md  docs/PIPELINE.md  docs/PRODUCT_VISION.md
-    docs/operations/INFRA.md
-    docs/architecture/adr/README.md      ← стаб реестра сквозных ADR (дир непустая, самоописуема)
-    docs/work-items/.gitkeep  docs/history/.gitkeep
-```
-
-Отвергнуто:
-- **`docs/_onboarding/`** — смешивает kit (продукт-артефакт, исходник для ЧУЖИХ репо) с
-  документацией самого орка; шаблоны промптов под `docs/` рядом с живыми `docs/_templates/`
-  провоцируют путаницу «какая копия живая» (прямо риск R-1/R-5 BRD) и ложные срабатывания
-  doc-тулинга.
-- **`scripts/onboarding/`** — смешивает данные (дерево skeleton) с исполняемым кодом; `scripts/`
-  в этом репо — плоские утилиты (`staging_check.py`, deploy-hook).
-
-Top-level каталог делает границу физической: **всё под `onboarding/` предназначено новому репо,
-ничто под `onboarding/` не исполняется рантаймом орка.** Структурные тесты канона гоняются по
-`onboarding/repo-skeleton/.openclaw/agents/*.md` отдельно от живых промптов орка (TC-03…08 ↔
-существующий `tests/test_agent_prompts_canon.py` не пересекаются).
-
-### D2 — Механизм подстановки: `{{NAME}}` + stdlib, без новых зависимостей (OQ-2)
-
-**Решение: синтаксис `{{PLACEHOLDER_NAME}}`** (верхний регистр, `[A-Z][A-Z0-9_]*`), подстановка —
-простой проход `str.replace` по словарю; после рендера — обязательный скан
-`re.compile(r"\{\{[A-Z][A-Z0-9_]*\}\}")` на неразрешённые плейсхолдеры (ошибка в apply/verify,
-PASS-условие AC-5/TC-09).
-
-- **`string.Template` отвергнут:** kit-шаблоны (INFRA.md, `.env.example`, промпты) содержат
-  shell-сниппеты с `$VAR`/`${VAR}` — синтаксис `$` коллидирует и потребовал бы экранирования по
-  всему kit (хрупко, нечитабельно).
-- **Jinja2 отвергнут:** новая pip-зависимость (ТЗ §9 запрещает без обоснования) + условная логика
-  в шаблонах = второй язык программирования в kit → выше риск дрейфа. Kit обязан быть тупым.
-- Синтаксис `{{…}}` визуально различим, greppable; в Markdown/YAML kit-файлов естественно не
-  встречается, остаточные случаи ловит скан.
-
-**Словарь — `onboarding/placeholders.json`** (машиночитаемый single source of truth; формат:
-`{ "NAME": {"description": …, "required": bool, "default": …|null, "example": …} }`):
-
-| Плейсхолдер | Смысл | Обяз. |
-|---|---|---|
-| `{{PROJECT_NAME}}` | человекочитаемое имя проекта | да |
-| `{{PROJECT_DESCRIPTION}}` | 1–2 фразы «зачем проект» (README/PRODUCT_VISION) | да |
-| `{{REPO}}` | имя Gitea-репо (== каталог под `/repos`) | да |
-| `{{GITEA_OWNER}}` | owner/org репо в Gitea | да |
-| `{{WORK_ITEM_PREFIX}}` | префикс work-item (`ET`/`ORCH`-аналог) | да |
-| `{{PLANE_PROJECT_ID}}` | uuid Plane-проекта (известен после Plane-шага apply) | да |
-| `{{STACK}}` | стек проекта (описательно) | да |
-| `{{TEST_CMD}}` | команда тестов (напр. `pytest -q`) | да |
-| `{{PROD_PORT}}` / `{{STAGING_PORT}}` | порты прод/staging | да |
-
-Расширение словаря = правка `placeholders.json` + kit + тестов в одном PR. Тесты держат
-**биекцию**: каждый плейсхолдер, встречающийся в kit, объявлен в словаре, и каждый объявленный —
-используется (нет мёртвых/опечаточных).
-
-### D3 — Copy-vs-template split (OQ-3, BR-2)
-
-| Класс | Файлы | Механизм |
-|---|---|---|
-| **Live-copy канона** (НЕ хранится в kit) | `docs/_templates/**` (16), `docs/_standards/**` (3) | копируются скриптом **verbatim из рабочего чекаута репо орка в момент материализации** |
-| **Параметризуемые шаблоны** (хранятся в kit) | 6 промптов, `CLAUDE.md`, `AGENTS.md`, `CONTRIBUTING.md`, `README.md`, `CHANGELOG.md`, `docs/ARCHITECTURE.md`, `docs/PIPELINE.md`, `docs/PRODUCT_VISION.md`, `docs/operations/INFRA.md`, `docs/architecture/adr/README.md`, `.env.example` | рендер `{{…}}` (D2) |
-| **Скелет-каркас** | `docs/work-items/.gitkeep`, `docs/history/.gitkeep` | копия как есть |
-
-- Канон копируется **байт-в-байт, без переписывания**: ORCH-примеры внутри стандартов
-  (`PIPELINE_DOCS.md` цитирует ORCH-088 и т.п.) остаются примерами — это не «утечка», а
-  иллюстрация (утечкой считается орк-литерал там, где должен быть параметр — AC-5/TC-10:
-  префикс work-item, порты 8500/8501, self-hosting-правила в паспорте/промптах).
-- Повторный `apply` существующие файлы в целевом репо **не перезаписывает** (идемпотентность
-  BR-9): обновление канона в уже-онбордженных репо едет их обычными PR с reviewer-gate;
-  новые онбординги автоматически получают свежий канон (live-copy, ТЗ §7).
-- Источник live-copy — чекаут, из которого запущен скрипт; скрипт проверяет наличие обоих
-  каталогов и (в verify) количество скелетов ≥ 16 / стандартов ≥ 3.
-
-### D4 — Скрипту разрешён read-only импорт `src` — закрытый список (OQ-4)
-
-**Решение: импортировать, не снапшотить.** Закрытый список импортов:
-
-| Импорт | Зачем |
-|---|---|
-| `src.projects._parse_projects_json`, `src.projects.ProjectConfig` | round-trip валидация генерируемой записи реестра фактическим парсером (AC-6/TC-12) |
-| `src.plane_sync._PLANE_NAME_TO_KEY` | точные канонические имена 22 статусов байт-в-байт (AC-7/TC-13) |
-| `src.config.settings` (read-only поля) | имена лейблов `auto_approve_label`/`auto_deploy_label`/`bug_fast_track_label` (дефолты `autoApprove`/`autoDeploy`/`Bug`), URL/токены Plane/Gitea из env |
-
-- **Почему не снапшот:** дублирование констант = гарантированный дрейф (R-2); AC-6 и так требует
-  фактический парсер; снапшот потребовал бы отдельного «теста синхронизации», который и есть
-  признание дрейфа. Импорт даёт нулевой дрейф **по построению**.
-- Импорт безопасен: `src.projects` → `src.config` (pydantic-settings с дефолтами, инстанцируется
-  без env); `src.plane_sync` module-level считает только строки из settings; `httpx` — уже
-  зависимость проекта (`requirements.txt`), **новых pip-зависимостей нет**.
-- Импорт приватных имён (`_parse_projects_json`, `_PLANE_NAME_TO_KEY`) — сознательная,
-  санкционированная ТЗ связь (ТЗ §2 разрешает явно). **Список закрыт:** любой новый импорт из
-  `src` — только через обновление этого ADR. Контроль ненарушения `src` — снапшот-тест TC-21
-  (`STAGE_TRANSITIONS`/`QG_CHECKS`) + AC-12 (diff).
-- Скрипт запускается из корня чекаута орка (runbook-предусловие); `sys.path`-шим в начале файла
-  (паттерн `scripts/staging_check.py`).
-
-### D5 — Plane-провижининг: канонические статусы + группы + fail-safe (OQ-5, BR-7)
-
-**Ensure-семантика:** `GET states` → создать недостающие по точным именам (ключи
-`_PLANE_NAME_TO_KEY`, 22 имени); существующие (включая CE-дефолтные Backlog/Todo/In Progress/
-Done/Cancelled нового проекта) — `skipped(exists)` по совпадению имени. Аналогично лейблы:
-`autoApprove`/`autoDeploy`/`Bug` (имена — из `settings`, D4).
-
-**Канонические группы статусов** (Plane: `backlog|unstarted|started|completed|cancelled`) —
-фиксируются этим ADR; код-критичные констрейнты выделены:
-
-| Статус | Группа | Констрейнт |
-|---|---|---|
-| Backlog | `backlog` | |
-| Todo, To Analyse | `unstarted` | |
-| In Progress, Analysis, Architecture, Development, Code-Review, Review, Testing, Awaiting Deploy, Deploying, Monitoring after Deploy, Needs Input, In Review, Blocked, Approved, Confirm Deploy | `started` | **рабочие/гейтовые статусы НЕ в терминальных группах** — иначе terminal-detection ORCH-068 (`{uuid→group}`, группы `completed`/`cancelled` = терминал) ложно сочтёт живую задачу терминальной |
-| Rejected | `started` | reject = rework-петля в анализ, задача жива → НЕ `cancelled` |
-| Done | `completed` | терминал |
-| Cancelled | `cancelled` | терминал |
-| **STOP** | **`cancelled`** | **требование ORCH-090** (fail-closed: без статуса/группы ветка cancel не активируется) |
-
-**Fail-safe (CE-пробелы):** код орка использует только GET states — доступность POST
-project/states/labels в Plane CE не гарантирована. Любой недоступный вызов (403/404/405/501/
-нереализовано) → шаг помечается **`manual-step`** со ссылкой на соответствующий раздел runbook
-(точное имя статуса + группа для ручного создания в UI), скрипт не падает (AC-7/TC-14).
-Заведомо ручные шаги: порядок статусов на доске (drag-and-drop, UI-only), workspace-webhook
-(существует, Ф-6 — verify печатает команду проверки, не создаёт).
-
-### D6 — Gitea-провижининг: репо + webhook + initial push только в пустой репо (BR-9)
-
-- **Репо:** `POST /api/v1/...` под `{{GITEA_OWNER}}`, `auto_init=false` (репо рождается пустым;
-  `main` создаёт initial push). Существует → `skipped(exists)`.
-- **Webhook (per-repo):** events `push`/`pull_request`/`status`, `content_type: json`,
-  `branch_filter: "*"`, URL = внешний URL орка `/webhook/gitea` (формат `SETUP_WEBHOOKS.md`).
-  **Секрет: приёмник `src/webhooks/gitea.py` валидирует ОДИН глобальный
-  `ORCH_GITEA_WEBHOOK_SECRET` на все репо** → скрипт **переиспользует** существующий секрет из
-  env (никогда не генерит новый при наличии — новый сломал бы HMAC всех вебхуков); секрет
-  отсутствует в env → сгенерить `secrets.token_hex(20)` + вывести оператору для `.env`
-  (первичная настройка). В логах/отчёте секрет всегда маскируется (NFR-3).
-- **Initial push:** материализованный kit коммитится (`feat: onboarding skeleton (ORCH-009 kit)`)
-  и пушится в `main` **только если репо свежесоздан/пуст** (Gitea `empty: true`); непустой репо →
-  `manual-step` (kit-файлы НИКОГДА не пушатся поверх существующего контента). Это единственный
-  разрешённый push: новый пустой репо до регистрации в реестре не является участником конвейера →
-  **INV-4 (мерж только через PR-merge API) не затрагивается** (ТЗ §9).
-
-### D7 — Запись реестра: полный merged-массив, скрипт `.env` не трогает (BR-8)
-
-**Решение: скрипт выводит (а) standalone-запись нового проекта и (б) полный merged-массив
-`ORCH_PROJECTS_JSON`** = существующие записи verbatim + новая в конец. Источник существующих:
-текущий env / `--env-file` (дефолт — `.env` в корне чекаута, если есть); источника нет → только
-standalone-запись + инструкция. Перед выводом merged-массив прогоняется через
-`projects._parse_projects_json` (round-trip: поля новой записи совпадают, существующие не
-потеряны/не искажены — AC-6/TC-12).
-
-- **Почему full-array, а не диф:** оператор вставляет одну строку в `.env` атомарно — ручное
-  слияние JSON в env-строке (экранирование, запятые) и есть источник ошибок R-4.
-- Скрипт **не правит** `.env` прода и **не рестартит** контейнер (NFR-2): печатает строку +
-  инструкцию «добавь в `.env` → управляемый рестарт оркестратора (self-hosting: групповое окно,
-  выполнять осознанно)» со ссылкой на runbook. `verify` после рестарта показывает разрыв
-  «создано, но не зарегистрировано» (R-4).
-
-### D8 — Песочница для smoke: staging-контур 8501 + одноразовый SMK-проект (OQ-6, AC-13)
-
-**Решение: smoke выполняется на staging-контуре** (`orchestrator-staging`, 8501, изолированная БД
-`./data/staging`) с **одноразовым** sandbox: Plane-проект `onboarding-smoke` (префикс `SMK`) +
-Gitea-репо `onboarding-smoke`, онбордженные самим скриптом. Регистрация — в `ORCH_PROJECTS_JSON`
-**staging-окружения** (`.env.staging`) + рестарт staging (свободен, в отличие от прод-инварианта).
-Прогон: тестовая задача SMK → стадия `analysis` → проверить следы чтения паспорта/`AGENTS.md` и
-артефакты `docs/work-items/SMK-…/` по канону `PIPELINE_DOCS.md`.
-
-- **Прод-контур отвергнут:** smoke-задача писала бы конвейерные строки в общую прод-БД и жила бы
-  в общей очереди с enduro/ORCH — шум и риск в общем инстансе (дух NFR-2).
-- Протокол прогона — раздел **«Журнал smoke-прогонов»** в `ONBOARDING.md` (дата, параметры,
-  PASS/FAIL по чек-листу AC-13); для приёмки ORCH-009 первый протокол обязателен, ссылка на него —
-  из `13-test-report.md` задачи. Судьба sandbox-артефактов: архив/удаление вручную по разделу
-  «Откат» runbook (скрипт не удаляет ничего — BR-9).
-
-### D9 — Языковая политика kit-промптов: канон орка (OQ-7, AC-4)
-
-**Решение: 5 ru + deployer en** — ровно языковая раскладка канона орка, нормативная по
-ADR-001 D2 ORCH-092 (deployer — самый safety-critical промпт, en-раскладка минимизирует
-регресс-поверхность байт-точных verdict-ключей/команд). Kit наследует канон без отступлений;
-per-project отступление возможно позже **только** решением в собственном ADR нового проекта
-(правило фиксируется в `onboarding/README.md` и шаблоне `CONTRIBUTING.md`). Проверяется TC-08.
-
-### D10 — Branch protection `main` нового репо: НЕ включать (OQ-8)
-
-**Решение: не включать.** Merge-актор конвейера — Gitea PR-merge API под токеном орка
-(INV-4; `src/merge_gate.py`, ORCH-093): required-approvals/required-status-checks дали бы
-405/409-класс отказов `merge_pr` → ложные HOLD (ровно класс инцидента ORCH-063). Сам орк живёт
-без protection — защита `main` держится конвенцией (агенты не пушат `main`; мерж только через
-PR API) и скоупом токенов. Решение фиксируется в runbook; пересмотр — при мультитенант-hardening
-(D5.6, вне объёма).
-
-### D11 — Форма CLI и тестируемость без сети (BR-11, NFR-5)
-
-**Один файл `scripts/onboard_project.py`** (операторская UX: один очевидный энтрипойнт; паттерн
-`scripts/staging_check.py`), внутри — слои:
-
-- **Чистое ядро:** `build_plan(params, observed) -> Plan` — без I/O; `Plan` = упорядоченный список
-  шагов закрытого списка BR-1: `plane.project → plane.states(22) → plane.labels(3) → gitea.repo →
-  gitea.webhook → kit.materialize+push → registry.emit`. Рендер kit — чистая функция
-  `render(text, params)` (D2), в plan-режиме выполняется **in-memory** (ни одной записи на диск —
-  AC-8/TC-16); материализация на диск (temp-dir → git init/commit/push) — только в `apply`.
-- **Тонкие клиенты** `PlaneClient`/`GiteaClient` (httpx; единственные точки сети) — инжектируются
-  → в тестах мокаются целиком (NFR-5: ноль сетевых вызовов, TC-13…18).
-- **Режимы:** `plan` (дефолт) — только GET-пробы текущего состояния + полный план без единой
-  мутации; `apply` — ensure-исполнение (идемпотентно, без delete-операций вовсе); `verify` —
-  GET-пробы + локальные проверки (registry round-trip, резолв всех логических ключей включая
-  `confirm_deploy`/`stop`, лейблы, webhook активен, kit-файлы в репо, скан неразрешённых
-  плейсхолдеров).
-- **Отчёт:** человекочитаемый + `--json`; статус каждого шага
-  `created | skipped(exists) | manual-step | planned | error`; exit-коды: `0` — чисто, `2` — есть
-  `manual-step`/gap в verify, `1` — ошибка. Каждый шаг логируется (BR-11).
-
----
-
-## Альтернативы (сводно)
-
-- **`docs/_onboarding/` / `scripts/onboarding/`** — отвергнуто (D1): смешение kit с живой докой
-  орка / данных с кодом.
-- **Jinja2 / `string.Template`** — отвергнуто (D2): новая зависимость и логика в шаблонах /
-  коллизия `$` с shell-сниппетами.
-- **Снапшот констант `src` + тест синхронизации** — отвергнуто (D4): узаконенный дрейф; импорт
-  даёт нулевой дрейф по построению.
-- **Генерация нового webhook-секрета per-repo** — отвергнуто (D6): приёмник валидирует один
-  глобальный секрет; новый сломал бы HMAC существующих вебхуков.
-- **Диф-вывод реестра** — отвергнуто (D7): ручное слияние JSON-в-env — источник ошибок R-4.
-- **Smoke на прод-контуре** — отвергнуто (D8): запись в общую прод-БД/очередь.
-- **Branch protection `main`** — отвергнуто (D10): ломает PR-merge API актора (ложные HOLD).
-
-## Последствия
-
-- **+** Turnkey-способность D5.2: один проход + runbook вместо археологии; тихие деградации
-  (статусы/лейблы/промпты) закрываются проверяемо (`verify` + структурные тесты).
-- **+** Нулевой риск рантайма: `src/**` байт-в-байт, нового кода в горячих путях нет, kill-switch
-  не нужен; регресс enduro/orchestrator невозможен по построению.
-- **+** Анти-дрейф структурный: live-copy канона (BR-2) + единые канон-тесты kit (NFR-4) +
-  биекция словаря плейсхолдеров.
-- **−** Операторские шаги остаются ручными (env + управляемый рестарт; UI-only Plane): осознанное
-  ограничение NFR-2 (никакой автоматики рестартов) — митигировано runbook + verify (видимый разрыв).
-- **−** Импорт приватных имён `src` связывает скрипт с внутренними идентификаторами — митигировано
-  закрытым списком (D4) и тем, что рефакторинг имён мгновенно валит импорт в тестах (видимая,
-  не тихая поломка).
-- **−** Kit-шаблоны промптов требуют сопровождения при эволюции канона — митигировано общими
-  структурными требованиями тестов (расхождение ловит CI, NFR-4).
-- **Откат:** удалить `onboarding/`, `scripts/onboard_project.py`, `docs/operations/ONBOARDING.md`,
-  тесты — репо в исходном состоянии (ТЗ §7); внешние сущности (sandbox/созданные проекты) —
-  вручную по разделу «Откат» runbook.
-
-## Ссылки
-
-- BRD: `docs/work-items/ORCH-009/01-brd.md` · TRZ: `02-trz.md` · AC: `03-acceptance-criteria.md`
-  · Test plan: `04-test-plan.yaml`
-- Сверено по коду: `src/projects.py` (`ProjectConfig`, `_parse_projects_json`, `_load_projects`),
-  `src/plane_sync.py:94-165` (`_DEFAULT_STATES`, `_PLANE_NAME_TO_KEY` — 22 имени, fail-closed
-  `Confirm Deploy`/`STOP`), `src/qg/checks.py::check_architecture_done`, `src/config.py`
-  (`auto_*_label`/`bug_fast_track_label`), `requirements.txt` (httpx уже есть)
-- Операции: `docs/operations/SETUP_WEBHOOKS.md` (формат Gitea-webhook; Plane workspace-webhook —
-  SQL-only), `docs/operations/INFRA.md`
-- Стандарты: `docs/_standards/PIPELINE_DOCS.md` (§4 ADR-naming), `HANDOFF_PROTOCOL.md`,
-  `TRACEABILITY.md`
-- ADR: adr-0001 (registry), adr-0017/0018 (паттерны условности), adr-0021/0022 (канон промптов/
-  трассировка), adr-0026 (STOP, группа `cancelled`), ORCH-092 `ADR-001` D2 (язык deployer),
-  сквозной **adr-0035-turnkey-project-onboarding**

docs/work-items/ORCH-009/07-infra-requirements.md

@@ -1,66 +0,0 @@
----
-work_item: ORCH-009
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 07 — Инфра-требования: ORCH-009 — Turnkey-онбординг проектов
-
-Work Item: **ORCH-009** · Repo: **orchestrator** · Стадия: architecture
-
-> Топология оркестратора **не меняется** (NFR-1/NFR-2: `src/**` и compose не трогаются).
-> Файл фиксирует **предусловия исполнения способности** (токены/доступы/контуры) и инфра-границы
-> операторского скрипта. Детали решений — `06-adr/ADR-001-turnkey-onboarding-kit-and-cli.md`.
-
-## I-1. Топология / окружения
-
-- **Прод (`orchestrator`, 8500):** не затрагивается. Скрипт не создаёт/не останавливает/не
-  рестартит контейнеры; в общую БД не пишет (читает только файлы чекаута и внешние API).
-- **Staging (`orchestrator-staging`, 8501, БД `./data/staging`):** контур smoke-прогона (ADR D8).
-  Регистрация sandbox-проекта — в `.env.staging`; рестарт staging — штатный, свободный
-  (прод-инвариант на него не распространяется).
-- **Новые внешние сущности** (создаются скриптом в `apply`): Plane-проект, Gitea-репо +
-  per-repo webhook. Аддитивно: существующие проекты/репо не модифицируются (BR-9).
-- **Запуск скрипта:** хост mva154, из корня чекаута репо orchestrator. Среда исполнения —
-  venv с `requirements.txt` (httpx уже в зависимостях; новых pip-зависимостей нет) **или**
-  `docker compose exec orchestrator python scripts/onboard_project.py …` (read-only к рантайму,
-  без рестартов). Канонический способ фиксирует runbook `docs/operations/ONBOARDING.md`.
-
-## I-2. Переменные окружения / секреты
-
-**Новых env-переменных не вводится.** Используются существующие (предусловия запуска):
-
-| Переменная | Роль в онбординге |
-|---|---|
-| `ORCH_PLANE_API_TOKEN` (+ `ORCH_PLANE_API_URL`, `ORCH_PLANE_WORKSPACE_SLUG`) | создание/чтение Plane-проекта, статусов, лейблов; токен с правом создания проектов в workspace |
-| `ORCH_GITEA_TOKEN` (+ Gitea base URL) | создание репо (под `{{GITEA_OWNER}}`), per-repo webhook; токен с правом create-repo + hooks |
-| `ORCH_GITEA_WEBHOOK_SECRET` | **переиспользуется** для webhook нового репо (приёмник валидирует один глобальный секрет, ADR D6); отсутствует → скрипт генерит и печатает оператору для `.env` |
-| `ORCH_PROJECTS_JSON` | источник существующих записей для merged-вывода (ADR D7); **применение новой строки — операторский шаг** |
-
-- Секреты — только в `.env`/`.env.staging` на хосте, в гит не попадают (правило #8 CLAUDE.md);
-  в логах/отчётах скрипта секреты маскируются (NFR-3).
-- Kit несёт собственный `.env.example` нового проекта (дескрипторы без значений) — канон секретов
-  транслируется в онбордируемые репо.
-
-## I-3. Деплой / рестарт
-
-- **Скрипт НИКОГДА не рестартит/не останавливает прод-контейнер** (NFR-2, self-hosting инвариант).
-- Регистрация проекта в реестре (Ф-3): правка `.env` (строка `ORCH_PROJECTS_JSON` из отчёта
-  скрипта) + **управляемый операторский рестарт** оркестратора — групповое окно для ВСЕХ проектов
-  общего инстанса; runbook помечает шаг self-hosting-предупреждением и командой проверки
-  (`GET /queue`, резолв статусов нового проекта).
-- TTL-self-heal статусов Plane (ORCH-068, 300с) рестарта не требует: статусы/лейблы, созданные
-  после регистрации, подхватываются без вмешательства.
-- Деплой самой задачи ORCH-009 — штатный конвейер: изменение docs/scripts/tests-only, образ
-  пересобирается стандартно, staging-гейт (8501) обязателен как обычно.
-
-## I-4. CI/CD
-
-- `.gitea/workflows/` — **без изменений**: новые тесты (`tests/test_onboarding_kit.py`,
-  `test_onboarding_script.py`, `test_onboarding_invariants.py`) подхватываются существующим
-  pytest-шагом; все детерминированы, без сети (NFR-5).
-- Инфра-предусловий в образе нет: скрипт — операторский CLI вне рантайма, в образ ничего
-  дополнительно не запекается.

docs/work-items/ORCH-009/10-tech-risks.md

@@ -1,42 +0,0 @@
----
-work_item: ORCH-009
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 10 — Технические риски: ORCH-009 — Turnkey-онбординг проектов
-
-Work Item: **ORCH-009** · Repo: **orchestrator** · Стадия: architecture
-
-> Информационный (гейтом не парсится). Детализирует риски BRD §8 (R-1…R-5) до уровня решений
-> `06-adr/ADR-001`; митигейшены привязаны к D-решениям и TC тест-плана.
-
-## Реестр рисков
-
-| ID | Риск | Вер. | Влия. | Митигейшн |
-|----|------|------|-------|-----------|
-| TR-1 | **Drift канона** (R-1): копия `_templates`/`_standards` в новых репо разъезжается с живым каноном орка; kit-промпты отстают от эволюции канона 52d | Сред. | Сред. | BR-2/D3: live-copy в момент онбординга, второй редактируемой копии канона нет; NFR-4: структурные канон-тесты kit (TC-03…08) ловят расхождение в CI; обновление онбордженных репо — их обычные PR |
-| TR-2 | **Тихая деградация Plane-контрактов** (R-2): опечатка в имени статуса/лейбла или неверная **группа** → fail-closed/fail-safe ветки (`Confirm Deploy`, `STOP`, авто-лейблы, `Bug`) молча не работают; рабочий статус в группе `completed`/`cancelled` → terminal-detection ORCH-068 ложно терминалит живую задачу | Сред. | Выс. | D4: имена импортируются из `_PLANE_NAME_TO_KEY` (нулевой дрейф по построению, TC-13); D5: канонические группы зафиксированы таблицей ADR с код-критичными констрейнтами (STOP→`cancelled`, терминальные группы только Done/Cancelled/STOP); `verify` резолвит ВСЕ логические ключи включая `confirm_deploy`/`stop` |
-| TR-3 | **Скрипт с боевыми токенами** (R-3): ошибка = разрушительное действие на общих Plane/Gitea | Низ. | Выс. | BR-9/D11: `plan` (GET-only) — дефолт; delete-операций в коде нет вовсе (TC-18); аддитивный ensure (TC-17); push только в свежесозданный пустой репо (`empty: true`, D6); существующие сущности не модифицируются |
-| TR-4 | **Разрыв «создано, но не зарегистрировано»** (R-4): оператор не применил env+рестарт → проект невидим для орка | Сред. | Сред. | D7: merged-массив одной строкой (без ручного слияния JSON); runbook: явный операторский шаг с self-hosting-предупреждением + команда проверки; `verify` показывает разрыв (TC-12, AC-11) |
-| TR-5 | **Утечка орк-специфики в kit** (R-5): новый репо получает ORCH-префикс, порты 8500/8501, self-hosting-правила орка | Сред. | Сред. | D2: скан неразрешённых плейсхолдеров после рендера; TC-10: явный тест на утечки; биекция словаря `placeholders.json` ↔ kit (мёртвые/опечаточные плейсхолдеры не живут) |
-| TR-6 | **Поломка HMAC существующих вебхуков**: генерация нового per-repo секрета при едином глобальном `ORCH_GITEA_WEBHOOK_SECRET` приёмника | Низ. | Выс. | D6: секрет **переиспользуется** из env (новый генерится только при полном отсутствии — первичная настройка); секрет маскируется в логах/отчёте (NFR-3) |
-| TR-7 | **Связь скрипта с приватными именами `src`** (`_parse_projects_json`, `_PLANE_NAME_TO_KEY`): рефакторинг src валит скрипт | Низ. | Низ. | D4: закрытый список импортов (расширение — только через ADR); поломка видимая, не тихая — импорт падает в тестах (TC-12/13) на том же PR, что рефакторит src; снапшот TC-21 гардит сам src |
-| TR-8 | **Plane CE API-пробелы** (OQ-5): POST project/states/labels недоступен в CE → провижининг неполон | Сред. | Низ. | D5: fail-safe деградация в `manual-step` со ссылкой на runbook (имя+группа для UI-создания), не падение (TC-14); `verify` подтверждает итоговую полноту независимо от способа создания |
-| TR-9 | **Smoke загрязняет общий контур**: прогон способности в проде = строки в общей БД/очереди | Низ. | Сред. | D8: smoke только на staging (8501, изолированная БД, `.env.staging`); sandbox-сущности одноразовые, снос вручную по разделу «Откат» runbook |
-
-## Сводный вывод
-
-Доминирующий класс — **операционные риски исполнения способности** (TR-2/TR-3/TR-4): они
-митигированы структурно (импорт констант вместо копий, GET-only дефолт, отсутствие delete-операций,
-verify-режим), а не дисциплиной. Рисков для прод-конвейера самой задачи **нет по построению**:
-`src/**` байт-в-байт (AC-12/TC-21), нового кода в горячих путях нет, kill-switch не требуется —
-способность активируется только явным запуском операторского CLI.
-
-Эскалация `arch:major-change` **не требуется**: ни новой стадии, ни нового рантайм-компонента,
-ни изменения БД — это docs/templates/scripts/tests-only способность (новая стадия/компонент
-конвейера не вводится). Возврат в анализ не требуется: ТЗ выполнимо без нарушения принципов.
-Остаточный риск для прод-конвейера (self-hosting): **низкий**.

docs/work-items/ORCH-009/12-review.md

@@ -1,167 +0,0 @@
----
-verdict: APPROVED
-work_item: ORCH-009
-stage: review
-author_agent: reviewer
-status: approved
-created_at: 2026-06-10
-model_used: claude-fable-5
-type: review
-work_item_id: ORCH-009
-version: 2
----
-
-# Review ORCH-009 — Turnkey-онбординг проектов (kit + CLI + runbook) — re-review (цикл 2)
-
-Ветка: `feature/ORCH-009-turnkey-plane` · Diff vs `origin/main`: 46 файлов, +5478/−12.
-Состав: kit `onboarding/repo-skeleton/` (28 файлов), CLI `scripts/onboard_project.py` (1090 строк),
-runbook `docs/operations/ONBOARDING.md`, 3 онбординг-тест-модуля (83 теста), golden-source доки,
-ADR×2 + индекс.
-
-**Контекст цикла:** review v1 (`APPROVED`, 3×P2/2×P3) → testing `PASS` → re-test merge-gate упал на
-**средовых** не-герметичных тестах ORCH-41-эры (прод-env `ORCH_AGENT_FALLBACK_MODEL`/
-`ORCH_AGENT_MODEL_DEFAULT`) → откат на development → фикс `e903818` (герметизация
-`tests/test_resolve_agent_{model,effort}.py`) + регенерация `17-security-report.md` (`b26a391`).
-Этот review: независимая проверка дельты цикла + выборочная верификация клеймов v1.
-
-## Summary
-
-**APPROVED.** P0/P1 нет. Дельта цикла (фикс герметичности тестов) корректна, трассирована к
-ORCH-074 ADR-001 Решение 3 и сохраняет его инвариант; полный регресс теперь зелёный **под
-фактическим прод-env** (перепроверено мной: 1713 passed, exit 0 — ровно та среда, что валила
-merge-gate до фикса). Клеймы review v1 выборочно перепроверены и подтверждены. Переносятся 3×P2
-(харднинг краевых путей CLI, не фикшены — легитимно, follow-up) + 3×P3. Документация обновлена в
-том же PR по всем точкам, включая отдельную CHANGELOG-запись про сам фикс тестов.
-
-## Оси проверки
-
-### Ось 1 — Соответствие ТЗ (`02-trz.md`, `03-acceptance-criteria.md`) — ✅
-
-| Требование | Статус | Чем подтверждено |
-|---|---|---|
-| FR-1 состав kit (19 элементов, анти-форк канона) | ✅ | TC-01/02 зелёные; `docs/_templates|_standards` в kit не хранятся — live-copy в `materialize_kit` (`LIVE_COPY_DIRS`, прочитан код) |
-| FR-2 канон 52d/92 промптов (5 секций, ❌→✅, `<escalation>`, 52c-схема, verdict-ключи байт-в-байт, плейсхолдерные даты/модели) | ✅ | TC-03…06 зелёные; verdict-ключи в kit-промптах сверены grep'ом (`verdict:`/`staging_status:`/`deploy_status:`/`security_status:` на месте) |
-| FR-2 reviewer-gate доки (AC-3) | ✅ | kit `reviewer.md:65`: «документация НЕ обновлена → вердикт ОБЯЗАТЕЛЬНО `REQUEST_CHANGES`» — прочитано лично |
-| FR-3 INFRA.md шаблон | ✅ | TC-19 зелёный (топология/env/границы/риски общего хоста); INFRA орка не тронут (diff пуст) |
-| FR-4 CLI plan/apply/verify | ✅ | Код прочитан полностью: `plan` GET-only (рендер in-memory), `apply` идемпотентный ensure без delete, 22 статуса из `_PLANE_NAME_TO_KEY` + `STATE_GROUPS` 1:1 c ADR D5, CE-отказ → `ManualStep` → `manual-step` (fail-safe); TC-13…18 зелёные |
-| FR-5 verify | ✅ | round-trip фактическим парсером, резолв всех 22 имён, лейблы, webhook active, полнота kit (`VERIFY_KIT_FILES`), скан `{{…}}`, канон ≥16/≥3 |
-| FR-6 runbook | ✅ | `ONBOARDING.md` прочитан: слои 0→6 в порядке BR-1, каждый 🖐-шаг с командой проверки, self-hosting-предупреждение «групповое окно» (§4.2), workspace-webhook — «существует, только проверка» (§1.5), откат §6 |
-| §4/§5 нет API/БД изменений | ✅ | diff `src/**` пуст (проверено лично) |
-| §9 инварианты | ✅ | `git diff origin/main...HEAD -- src/ .openclaw/ docs/_templates/ docs/_standards/ docs/operations/INFRA.md requirements.txt` — **пусто**; сетевых вызовов в тестах нет (фейк-клиенты); новых pip-зависимостей нет |
-| AC-12 полный регресс | ✅ | **1713 passed, 0 failed, exit 0** — мой прогон в worktree ветки под фактическим хост-env (до фикса здесь было 2 failed) |
-| AC-13 операторский smoke | ⏳ | По построению операторский (ADR D8); «Журнал smoke-прогонов» — плейсхолдер. Обязателен ДО `Confirm Deploy` — см. handoff |
-
-### Ось 2 — Соответствие ADR (`06-adr/ADR-001` D1–D11, сквозной `adr-0035`) — ✅
-
-- **D1** top-level `onboarding/` ✅; **D2** `{{NAME}}` + `str.replace` + обязательный пост-скан
-  (`PLACEHOLDER_RE`, ValueError в `materialize_kit`) + биекция словаря тестом ✅; **D3**
-  live-copy verbatim, существующие файлы не перезаписываются ✅; **D4** закрытый список импортов
-  `src` — в скрипте ровно три (`settings`, `_PLANE_NAME_TO_KEY`, `_parse_projects_json`),
-  загвожден AST-тестом TC-21 ✅; **D5** `STATE_GROUPS` 1:1 с таблицей ADR (22 имени, set-равенство
-  с `_PLANE_NAME_TO_KEY` тестом; `STOP`→`cancelled`; терминальные группы только
-  Done/Cancelled/STOP; `Rejected`→`started`) ✅; **D6** `auto_init=False`, переиспользование
-  глобального HMAC-секрета, push только в свежесозданный/пустой репо ✅; **D7** merged-full-array
-  + round-trip + `.env` read-only ✅; **D8** smoke на staging 8501, журнал в runbook ✅; **D9**
-  5 ru + deployer en с «Do NOT translate»-гардом и рамкой shared-host-гардрейлов (прочитано
-  лично) ✅; **D10** runbook §2.3 «branch protection НЕ включать» ✅; **D11** plan/apply/verify,
-  чистый `build_plan`, инжектируемые клиенты, отчёт `created/skipped(exists)/manual-step/planned/
-  error`, exit-коды 0/2/1 ✅.
-- **Трассировка (`docs/_standards/TRACEABILITY.md`) — дельта цикла:**
-  - `tests/test_resolve_agent_{model,effort}.py` несут маркеры **ORCH-41/ORCH-074** — сверено с
-    `docs/work-items/ORCH-074/06-adr/ADR-001-model-name-validation.md` **Решение 3 (G4)**:
-    инвариант = «**shipped-дефолт** `agent_fallback_model` остаётся `""`». Фикс переводит ассерт
-    с env-backed singleton на **класс-дефолт поля** (`model_fields[...].default == ""`) — это
-    и есть подлинный инвариант ADR (заводской дефолт, а не рантайм-конфиг оператора);
-    never-break ассерты `is_valid_model` — байт-в-байт. Инвариант **сохранён и уточнён**,
-    обоснование — в коммит-месседже и инлайн-комментариях со ссылкой на ADR. Чужой инвариант
-    не сломан → finding нет.
-  - `docs/architecture/adr/README.md` — бэкфилл строк 0032–0035 сверен: все 4 файла
-    (`adr-0032-bug-fast-track`, `adr-0033-sidecar-watchdog`, `adr-0034-lessons-journal`,
-    `adr-0035-turnkey-project-onboarding`) существуют, привязки задач корректны, «текущий
-    максимум 0035» верен.
-  - `docs/operations/SETUP_WEBHOOKS.md` — обобщение per-repo **усиливает** инвариант одного
-    глобального HMAC-секрета (явное предупреждение про ротацию на всех репо разом).
-- **Инварианты NFR-1/INV-4:** снапшот-тесты `STAGE_TRANSITIONS`/`QG_CHECKS` зелёные; push —
-  только initial в пустой репо вне конвейера; PR-merge API не затрагивается.
-
-### Ось 3 — Качество кода — ✅ (с переносными P2 ниже)
-
-- CLI: чистое разделение слоёв (ядро без I/O / тонкие клиенты / режимы), docstrings на всех
-  публичных функциях, единственная точка subprocess (только `git`, токен в логе маскируется
-  `://***@`), `ManualStep` fail-safe вместо падений, delete-операций нет вовсе, секрет в отчёте
-  `***` + тест non-leak. Тесты содержательные: AST-проверка закрытого списка импортов,
-  monkeypatch-мины на мутации в dry-run, негативные CE-сценарии, set-равенство против дрейфа
-  констант — не тривиальные.
-- **Фикс герметичности (дельта цикла) — корректен:** autouse-фикстуры пиняют shipped-дефолты
-  (зеркально между файлами-сиблингами), в чистом env поведение байт-эквивалентно; класс среды
-  merge-gate re-test (прод-env) теперь покрыт. Перепроверено прогоном: 1713 passed под хост-env.
-  Правка существующих тестов вне инвентаря ТЗ §2 — легитимна: инвентарь «рабочее предложение»,
-  ни один инвариант §9 не запрещает правку тестов; без неё PR непроходим через merge-gate
-  (латентная мина `main`, детонированная сменой прод-env).
-- Багфикс-трек (ORCH-019, BR-4): не применим — задача не `Bug`, маршрут полный.
-
-### Ось 4 — Документация — ✅ ОБНОВЛЕНА В ТОМ ЖЕ PR
-
-| Точка | Статус |
-|---|---|
-| `CLAUDE.md` — раздел «Turnkey-онбординг проектов (ORCH-009)» | ✅ |
-| `docs/architecture/README.md` — раздел + ссылки на оба ADR | ✅ (diff прочитан, фактам соответствует) |
-| `CHANGELOG.md` — детальная `feat`-запись **+ отдельная под-запись про фикс герметичности тестов** | ✅ (дельта цикла задокументирована — образцово) |
-| ADR per-WI `06-adr/ADR-001` + сквозной `adr-0035` + индекс `adr/README.md` | ✅ |
-| `docs/operations/ONBOARDING.md` (новый runbook) | ✅ |
-| `docs/operations/SETUP_WEBHOOKS.md` — обобщён per-repo | ✅ |
-| `onboarding/README.md` — устройство kit, словарь, анти-форк | ✅ |
-| README «Известные ограничения» (ORCH-079) | **N/A — проверено лично:** открыты 3 пункта (Telegram 48h / intra-repo deps ORCH-026 / пакетный автоном Этап 1) — ни один этим PR не закрывается |
-| `17-security-report.md` | ✅ `security_status: PASS` (0 secrets, 0 blocking) |
-| `08-data-requirements.md` отсутствует | Легитимно: гейт `check_analysis_complete` требует 01–04; ТЗ §5 «изменений БД нет» |
-
-## Findings
-
-### P0 — Blocker
-- (нет)
-
-### P1 — Must fix
-- (нет)
-
-### P2 — Should fix (перенос из review v1 — не фикшены, перепроверены: всё ещё в коде; follow-up, не блокируют)
-- [ ] **Quoted-значение в `.env` → тихая потеря существующих записей в merged-выводе.**
-  `read_existing_registry` (строка ~355) возвращает значение после `=` как есть; кавычки →
-  `json.loads` в `merged_projects_json` молча даёт `existing=[]` → merged-массив только с новым
-  проектом, а runbook §4.1 велит «заменить строку». Доминирующий путь безопасен (pydantic
-  снимает кавычки), потому P2. Рекомендация: `strip("'\"")` в фоллбеке + GAP-warning, если строка
-  в `.env` есть, а existing пуст. (ADR D7 «существующие не теряются».)
-- [ ] **`GiteaClient.create_repo`: фоллбек `POST /user/repos` может создать репо в чужом
-  namespace** (строки ~474–477): owner не org и не юзер токена → репо рождается под юзером
-  токена, последующие шаги по `owner/repo` дают 404/manual-step. Рекомендация: сверять
-  `owner.login` ответа с запрошенным; расхождение → `manual-step`.
-- [ ] **CE-деградация Plane + успешный Gitea в одном apply запекает литерал
-  `<assigned-on-apply>` в запушенный паспорт** (`build_params` → `PLANE_PROJECT_ID`); скан ловит
-  только `{{…}}`. Рекомендация: при неразрешённом `PLANE_PROJECT_ID` деградировать
-  `kit.materialize`/`kit.push` в `manual-step` ИЛИ добавить `<assigned-on-apply>` в скан verify.
-
-### P3 — Nice to have
-- [ ] `--env-file` игнорируется в `plan` (`run_plan` → `_registry_instructions(report, params,
-  None)`; `main()` его в `run_plan` и не передаёт): превью merged-массива может расходиться с apply.
-- [ ] Push-URL с `oauth2:<token>@` остаётся в `.git/config` temp-каталога после успешного apply
-  (cleanup нет). Рекомендация: чистить на успехе, на ошибке сохранять для дебага.
-- [ ] *(новое)* `run_apply`: шаг `registry.emit` добавляется со статусом `CREATED` **до**
-  `_registry_instructions`, который на ошибке round-trip добавляет второй шаг `registry.emit`
-  со статусом `ERROR` → дубль step-id в отчёте (exit-код при этом честный — 1). Косметика отчёта.
-
-## Документация
-
-Обновлена полностью в том же PR (таблица оси 4). Несоответствий «код изменён — дока молчит» нет;
-дельта цикла (фикс тестов) получила собственную CHANGELOG-запись с диагнозом и обоснованием;
-обзорная витрина README задачей не затрагивается (проверено: открытые ограничения не про онбординг).
-
-## Для следующей стадии (testing) — handoff
-
-1. **AC-13 (операторский smoke, ADR D8)** — единственный непокрытый pytest'ом AC: прогон по
-   runbook §5.2 (staging 8501, sandbox `SMK`) должен быть выполнен и запротоколирован в «Журнале
-   smoke-прогонов» `ONBOARDING.md`, ссылка — из `13-test-report.md`. Обязателен **до**
-   `Confirm Deploy` (человеческий гейт — точка контроля сохраняется).
-2. Средовая мина merge-gate обезврежена фиксом `e903818`: полный регресс зелёный и в чистом env,
-   и под прод-env (1713 passed, проверено в этом review) — спец-обвязка прогона больше не нужна.
-3. `13-test-report.md` в дереве — от прошлого цикла (до `e903818`): его строка «PR эти файлы не
-   трогает» про `tests/test_resolve_agent_*` устарела. Перегенерировать отчёт штатно (артефакт
-   чужой стадии — в этом review не правился).

docs/work-items/ORCH-009/13-test-report.md

@@ -1,117 +0,0 @@
----
-result: PASS   # PASS | FAIL — машинный вердикт, UPPERCASE
-work_item: ORCH-009
-stage: testing
-author_agent: tester
-status: pass
-created_at: 2026-06-10
-model_used: claude-opus-4-8
-type: test-report
-work_item_id: ORCH-009
----
-
-# Test Report — ORCH-009 — Turnkey-онбординг проектов (kit + CLI + runbook)
-
-> Машинный вердикт читается ТОЛЬКО из frontmatter (`result:`). Перепрогон стадии testing на
-> opus после сброса session-limit (ре-ран по запросу). Review-вердикт цикла 2 — `APPROVED`
-> (`12-review.md`, P0/P1 нет). Дельта цикла (герметизация ORCH-41-тестов `e903818`) перепроверена
-> полным регрессом под фактическим окружением worktree.
-
-## Окружение
-- Python: 3.12.13
-- pytest: 8.3.3 (pytest-cov 5.0.0, asyncio 0.23.8)
-- Дата: 2026-06-10
-- Worktree: `feature/ORCH-009-turnkey-plane` (`/repos/_wt/orchestrator/feature_ORCH-009-turnkey-plane`, HEAD `b97ffae`)
-- Прод-контейнер `orchestrator` (8500) — НЕ трогался (smoke read-only).
-
-## Smoke API (read-only)
-- `GET /health` → `{"status":"ok","service":"orchestrator"}` ✅
-- `GET /status` → отвечает; задача ORCH-009 (task 87) на стадии `testing` ✅
-- `GET /queue` → блок `serial_gate` **присутствует** (ORCH-088) ✅; блок `auto_labels` присутствует ✅
-  (полный набор ключей: `auto_labels, bug_fast_track, build_cache_prune, counts, coverage,
-  disk_monitor, fs_ownership, lessons, max_concurrency, merge_verify, poll_interval, post_deploy,
-  reaper, recent, reconcile, resilience, serial_gate, stop, task_deps`).
-
-## Результаты
-
-### Полный регресс
-`pytest tests/ -q` → **1713 passed, 0 failed, 1 warning** за 65.40s (exit 0). Прод-контейнер не
-трогался. Средовая мина merge-gate цикла 1 обезврежена фиксом `e903818` — регресс зелёный.
-
-### Профильные сюиты (онбординг)
-`pytest tests/test_onboarding_kit.py tests/test_onboarding_script.py tests/test_onboarding_invariants.py -v`
-→ **83 passed, 0 failed** за 0.55s (exit 0). Сетевых вызовов нет (Plane/Gitea — фейк-клиенты, NFR-5).
-
-### Сопоставление с тест-планом (`04-test-plan.yaml`)
-
-| TC ID | Описание | Тест-функция | Рез. |
-|-------|----------|--------------|------|
-| TC-01 | Kit содержит все элементы FR-1 (6 промптов + доки) | `test_tc01_kit_contains_all_required_elements`, `test_tc01_kit_readme_and_placeholder_dictionary_exist` | PASS |
-| TC-02 | Материализация добавляет live-копии `_templates`/`_standards`; форк канона отсутствует | `test_tc02_materialise_live_copies_canon`, `test_kit_does_not_fork_the_canon` | PASS |
-| TC-03 | 5 XML-секций в нормативном порядке (6 ролей) | `test_tc03_five_xml_sections_in_normative_order[*]` | PASS |
-| TC-04 | `<escalation>` у dev/rev/tester; запреты «❌→✅» | `test_tc04_escalation_section_after_success_criteria[*]`, `test_tc04_bans_use_cross_check_format[*]` | PASS |
-| TC-05 | Директивы доки (читай паспорт/AGENTS/ADR; пиши в work-items; CHANGELOG) | `test_tc05_prompt_directs_agent_to_docs[*]`, `test_tc05_changelog_duty_present[*]`, `test_tc05_architect_carries_adr_rules` | PASS |
-| TC-06 | 6-польная схема 52c; verdict-ключи байт-в-байт; даты/модели — плейсхолдеры | `test_tc06_six_schema_fields_named[*]`, `test_tc06_schema_pins_role_author_and_stage[*]`, `test_tc06_machine_verdict_keys_byte_exact`, `test_tc06_dates_and_models_are_placeholders[*]` | PASS |
-| TC-07 | reviewer-gate: дока не обновлена → `REQUEST_CHANGES` | `test_tc07_reviewer_gate_docs_not_updated_means_request_changes` | PASS |
-| TC-08 | Языковая политика (5 ru + deployer en) | `test_tc08_ru_canon_for_five_roles[*]`, `test_tc08_deployer_is_english` | PASS |
-| TC-09 | Рендер подставляет все плейсхолдеры (нет неразрешённых) | `test_tc09_render_resolves_all_placeholders`, `test_render_is_a_pure_replace` | PASS |
-| TC-10 | Нет утечек орк-специфики (ORCH-/8500/8501/self-hosting) | `test_tc10_no_orchestrator_specific_leaks` | PASS |
-| TC-11 | Ссылочная целостность отрендеренных промптов/AGENTS | `test_tc11_referenced_paths_exist_in_materialised_tree` | PASS |
-| TC-12 | Registry round-trip через фактический `_parse_projects_json`; существующие записи целы | `test_tc12_registry_round_trip_through_actual_parser`, `test_tc12_merge_is_idempotent_no_duplicates` | PASS |
-| TC-13 | План Plane: все статусы `_PLANE_NAME_TO_KEY` (вкл. `Confirm Deploy`/`STOP`) + лейблы | `test_tc13_plan_covers_all_statuses_and_labels`, `test_state_groups_match_plane_name_to_key` | PASS |
-| TC-14 | Недоступный Plane-шаг → `manual-step` (не падение/не молча) | `test_tc14_plane_refusal_becomes_manual_step` | PASS |
-| TC-15 | План Gitea: репо + webhook (push/pr/status + HMAC) + initial push | `test_tc15_plan_contains_gitea_repo_webhook_and_push` | PASS |
-| TC-16 | dry-run (plan) — ноль мутаций | `test_tc16_plan_is_a_pure_dry_run`, `test_secret_never_leaks_into_report` | PASS |
-| TC-17 | Повторный apply: `skipped(exists)`, без дублей/удалений; отчёт created/skipped/manual | `test_tc17_second_apply_skips_everything_existing` | PASS |
-| TC-18 | Нет операций рестарта/правки прод-.env/push в существующие репо (NFR-2) | `test_tc18_fresh_apply_runs_git_only_inside_workdir`, `test_tc18_source_has_no_container_or_env_mutation_ops` | PASS |
-| TC-19 | INFRA.md шаблон: обязательные секции; INFRA орка не тронут | `test_tc19_infra_template_mandatory_sections`, `test_tc19_orchestrator_own_infra_untouched_sections` | PASS |
-| TC-20 | Runbook: слои предусловия→Plane→Gitea→kit→регистрация→верификация→откат | `test_tc20_runbook_exists_and_layer_order`, `test_tc20_runbook_manual_steps_and_selfhosting_warning`, `test_tc20_runbook_verification_and_smoke_journal` | PASS |
-| TC-21 | Снапшот `STAGE_TRANSITIONS`/`QG_CHECKS`; `src/**` не ссылается на онбординг; закрытый список импортов | `test_tc21_stage_transitions_snapshot`, `test_tc21_qg_checks_registry_snapshot`, `test_tc21_src_never_references_onboarding`, `test_tc21_cli_src_imports_stay_in_closed_list`, `test_tc21_kit_prompts_name_only_real_gates` | PASS |
-| TC-22 | Полный регресс `tests/` зелёный | весь прогон `pytest tests/` (1713 passed) | PASS |
-
-**Итого тест-плана: 22/22 TC выполнены и PASS.**
-
-### Сопоставление с критериями приёмки (`03-acceptance-criteria.md`)
-
-| AC | Покрытие | Результат |
-|----|----------|-----------|
-| AC-1 Kit полон | TC-01 | PASS |
-| AC-2 Канон 52d/92 промптов | TC-03/04/05/06 | PASS |
-| AC-3 Reviewer-gate доки | TC-07 | PASS |
-| AC-4 Языковая политика | TC-08 | PASS |
-| AC-5 Материализация / нет утечек | TC-02/09/10/11 | PASS |
-| AC-6 Registry round-trip | TC-12 | PASS |
-| AC-7 План Plane (статусы/лейблы) | TC-13/14 | PASS |
-| AC-8 План Gitea + dry-run без мутаций | TC-15/16 | PASS |
-| AC-9 Идемпотентность/безопасность apply | TC-17/18 | PASS |
-| AC-10 INFRA.md шаблон | TC-19 | PASS |
-| AC-11 Runbook полон | TC-20 | PASS |
-| AC-12 `src/**` не тронут (снапшот + регресс) | TC-21/22 | PASS |
-| AC-13 Операторский smoke на песочнице | вне pytest (см. ниже) | DEFERRED (операторский гейт до `Confirm Deploy`) |
-
-## AC-13 — операторский smoke (не блокирует ребро testing → deploy-staging)
-AC-13 по построению (ADR D8, scope-нота `04-test-plan.yaml`) — **документированный операторский
-прогон** на песочнице staging 8501 с реальными Plane/Gitea-вызовами. Это мутирующая операторская
-процедура → вне read-only smoke и автоматизированного скоупа тестера. «Журнал smoke-прогонов»
-в `docs/operations/ONBOARDING.md` сейчас — плейсхолдер (прогон не выполнен).
-- **Не блокирует данную стадию:** AC-13 обязателен **до `Confirm Deploy`** (человеческий гейт
-  прод-деплоя, ORCH-059), который наступает ПОСЛЕ `deploy-staging`. Ребро `testing → deploy-staging`
-  он не гейтит (это операторская страховка, а не Quality Gate; `QG_CHECKS` не содержит проверки AC-13).
-- **Handoff оператору:** выполнить runbook §5.2 (staging 8501, sandbox-префикс) и запротоколировать
-  результат в «Журнале smoke-прогонов» `ONBOARDING.md` **перед** нажатием `Confirm Deploy`.
-
-## Вывод pytest (итоги)
-```
-# полный регресс
-1713 passed, 1 warning in 65.40s (exit 0)
-
-# профильные сюиты онбординга
-83 passed, 1 warning in 0.55s (exit 0)
-```
-(Единственный warning — `PydanticDeprecatedSince20` в `src/config.py:8`, существующий, не связан с задачей.)
-
-## Итог
-**PASS.** Полный регресс зелёный (1713 passed), все 22 TC тест-плана выполнены и PASS, все
-машинно-проверяемые AC (1–12) закрыты, read-only smoke API в норме (`serial_gate`/`auto_labels`
-в `/queue` присутствуют). AC-13 — операторский smoke, отложен к гейту `Confirm Deploy` (не блокирует
-переход на `deploy-staging`). Задача готова к стадии `deploy-staging`.

docs/work-items/ORCH-009/14-deploy-log.md

@@ -1,12 +0,0 @@
----
-deploy_status: SUCCESS
-work_item: ORCH-009
-hook_exit_code: 0
-deployed_by: deploy-finalizer
----
-
-# Deploy log — ORCH-036 executable self-deploy
-
-Прод-деплой завершён хост-хуком с exit-code `0` -> `deploy_status: SUCCESS`.
-
-Вердикт зафиксирован детерминированным finalizer'ом (Фаза C), не LLM.

docs/work-items/ORCH-009/17-security-report.md

@@ -1,25 +0,0 @@
----
-security_status: PASS
-secrets_found: 0
-deps_blocking: 0
-deps_warning: 4
-deps_audit_degraded: false
----
-# Security Report — ORCH-009
-
-Детерминированный security-гейт (ORCH-022): secret-scanning (gitleaks, offline) + dependency audit (pip-audit). Машинный вердикт читается ТОЛЬКО из frontmatter выше.
-
-## Verdict
-clean: 0 secrets, 0 blocking CVE(s)
-
-## Secrets
-- None
-
-## Dependencies (blocking)
-- None
-
-## Dependencies (warning)
-- `pytest==8.3.3` — GHSA-6w46-j5rx-g56g severity=UNKNOWN fix=9.0.3
-- `starlette==0.38.6` — PYSEC-2026-161 severity=UNKNOWN fix=1.0.1
-- `starlette==0.38.6` — GHSA-f96h-pmfr-66vw severity=UNKNOWN fix=0.40.0
-- `starlette==0.38.6` — GHSA-2c2j-9gv5-cj73 severity=UNKNOWN fix=0.47.2

docs/work-items/ORCH-101/00-business-request.md

@@ -1,7 +0,0 @@
-# Business Request: ORCH-10-common: расхардкод + секреты + smoke (фундамент тиража)
-
-Work Item ID: ORCH-101
-
-## Description
-
-TBD

docs/work-items/ORCH-101/01-brd.md

@@ -1,175 +0,0 @@
----
-work_item: ORCH-101
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 01 — BRD (бизнес-требования): ORCH-101 — ORCH-10-common: расхардкод + секреты + smoke (фундамент тиража)
-
-Work Item: **ORCH-101** · Repo: **orchestrator** · Стадия: analysis
-
-## 1. Бизнес-контекст и проблема
-
-Эпик **ORCH-10** (домен 📈 D5 «Масштаб», `docs/epics/self-evolution.md`, D5.3) — тираж платформы
-для раздачи **текущей** функциональности нескольким заказчикам **на тест**. Решения Славы 10.06:
-
-- **Два типа тиража, оба stateless** (наши задачи/данные НЕ переносятся, чистый старт):
-  - **Тип A (Lite):** перенос орк + watchdog на новую инфру; окружение донастраивается по чёткой
-    инструкции.
-  - **Тип B (Bundled):** весь стек (Plane/Gitea/орк) одним комплектом.
-- **ORCH-101 = 10-common** — общий фундамент **обоих** типов. Без него ни Lite, ни Bundled не поедут.
-
-**Проблема.** Платформа фактически прибита гвоздями к хосту `mva154`:
-
-1. **Хардкоды хоста/окружения.** Аудит репо (стадия analysis, см. реестр в `02-trz.md` §3.1)
-   подтвердил: в `src/**` есть код, который **обходит конфиг** — внешний URL Gitea
-   `http://git.mva154.duckdns.org` зашит в `src/plane_sync.py`, `HOME=/home/slin` и git-идентичность
-   `*@mva154.local` зашиты в трёх местах (`launcher`/`self_deploy`/`post_deploy`); в
-   `docker-compose.yml` зашиты пути `/home/slin/...`, gid docker-группы `999`, uid `1000:1000`,
-   node-пути; в `Dockerfile` — `useradd … -d /home/slin slin` и порт CMD; в
-   `scripts/orchestrator-deploy-hook.sh` — `REPO=/home/slin/repos/orchestrator`. На новом хосте
-   (другой пользователь, другие пути, другой gid docker, другие URL) платформа не заведётся без
-   правки кода — это блокер тиража.
-2. **Секреты.** Боевые секреты (`.env`) копировать на чужую инфраструктуру нельзя (общий
-   webhook-secret = чужой хост сможет слать нам валидные вебхуки; утечка токенов). Механизма
-   «сгенерировать НОВЫЙ комплект секретов на новом хосте» нет; `.env.example` не имеет чек-листа
-   «что обязан заполнить оператор».
-3. **Верификация.** Нет процедуры убедиться, что развёрнутая копия платформы **жива**: «завести
-   тестовый проект + задачу → конвейер доехал». Без неё каждый тираж — слепой деплой.
-
-**Ценность:** после ORCH-101 платформа разворачивается на новой инфре конфигурацией (env), с
-собственными секретами и проверяется воспроизводимым smoke-прогоном. Это критический путь всего
-эпика ORCH-10.
-
-## 2. Объём (scope)
-
-### В объёме
-
-1. **Расхардкод** — вынести все хардкоды хоста/окружения в конфиг/env **с дефолтами, равными
-   текущим значениям**: IP/hostname (`82.22.50.71`, `mva154`, `*.duckdns.org`), пути
-   (`/home/slin/...`, `/repos`), порты (8500/8501/3000/8091), gid docker `999`, uid `1000`, имена
-   контейнеров/сервисов/образов, URL Plane/Gitea, git-идентичность агентов. Зоны:
-   `src/**`, `watchdog/**`, `docker-compose.yml`, `Dockerfile`, `scripts/`, `.env.example`.
-   Аудит — **весь репо** (нормативный реестр находок — `02-trz.md` §3.1).
-2. **Секреты** — механизм генерации **новых** секретов на новом хосте (webhook-секреты —
-   криптослучайная генерация на месте; внешние токены Plane/Gitea/Telegram — выпуск на целевых
-   системах по чек-листу). Полный шаблон `.env.example` с плейсхолдерами + чек-лист «что заполнить».
-   Боевые секреты не покидают текущий хост.
-3. **Smoke-верификация** — документированная воспроизводимая процедура (и/или скрипт-обвязка):
-   «завести тестовый проект + задачу → конвейер доехал», с чёткими критериями PASS/FAIL.
-4. **Анти-регресс** — структурный тест (grep-тест по образцу `tests/test_agent_prompts_canon.py`),
-   запрещающий возврат хост-хардкодов в `src/**`.
-5. **Доки** — deployment-раздел (параметризация, карта новых env-ключей, чек-лист секретов,
-   smoke-процедура) + обновление карты env в `docs/operations/INFRA.md` + `CHANGELOG.md`.
-
-### Вне объёма
-
-- **Сама инструкция тиража Типа A (Lite) end-to-end** и **сборка комплекта Типа B (Bundled)** —
-  отдельные задачи эпика ORCH-10; 10-common даёт им фундамент.
-- **Перенос данных/задач/истории** — тираж stateless по решению Славы 10.06 (чистый старт).
-- **Мультитенантность** (D5.6), горизонтальный воркер-пул (D5.4), IaC-автоматизация
-  (Terraform/Ansible) — не сейчас.
-- **Изменение конвейера**: `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict ключи /
-  схема БД — не трогаются (задача конфигурационная, не процессная).
-- **Расхардкод исторических документов** `docs/**`, `memory/**`, `CHANGELOG.md` — историческая
-  правда не переписывается; аудит судит **код и инфра-файлы**, не архив.
-- **`tests/**`** — тестам разрешены литералы как фикстуры/ожидания.
-- **Onboarding-kit** (`onboarding/`, ORCH-009) — уже параметризован плейсхолдерами `{{NAME}}`;
-  правится только при необходимости согласовать новые env-ключи.
-
-## 3. Заинтересованные стороны
-
-- **Слава (Owner)** — заказчик эпика ORCH-10; принимает BRD (гейт Approved) и прод-деплой
-  (Confirm Deploy).
-- **Будущие заказчики-тестеры** — потребители тиража Типов A/B (получают платформу на своей инфре).
-- **Стрим** — оператор тиража: выполняет инструкцию, генерирует секреты, гоняет smoke.
-- **Последующие задачи эпика ORCH-10 (Lite/Bundled)** — прямые потребители фундамента.
-- **Агенты конвейера / self-hosting** — изменения катятся через общий прод-инстанс; регресс на
-  текущем хосте недопустим (обслуживает и enduro-trails).
-
-## 4. Бизнес-требования (BR)
-
-- **BR-1 (расхардкод src)** — в `src/**` и `watchdog/**` не остаётся хост-специфичных литералов
-  (IP/hostname/пути/порты/URL/идентичности), **обходящих конфиг**: каждое такое значение читается
-  из `Settings` (env `ORCH_*` / `WATCHDOG_*`) с дефолтом, равным текущему боевому значению.
-  Дефолты в `src/config.py` / `watchdog/config.py` — легитимное место значений по умолчанию.
-- **BR-2 (расхардкод инфра-файлов)** — `docker-compose.yml`, `Dockerfile`,
-  `scripts/orchestrator-deploy-hook.sh` параметризованы (compose-интерполяция `${VAR:-default}`,
-  `ARG`, env-override соответственно); без заданных переменных конфигурация резолвится в текущие
-  значения 1:1.
-- **BR-3 (секреты)** — существует механизм получения **нового** комплекта секретов на новом хосте:
-  генерируемые локально (webhook-секреты) создаются криптослучайно; выпускаемые внешними системами
-  (токены Plane/Gitea/Telegram) перечислены в чек-листе с указанием, где их выпустить.
-  `.env.example` покрывает 100% обязательных ключей. Копирование боевых секретов не требуется ни
-  на одном шаге.
-- **BR-4 (smoke)** — существует документированная воспроизводимая процедура верификации тиража:
-  «развёрнутый инстанс → тестовый проект + задача → конвейер доехал», с момента старта до явного
-  PASS/FAIL-критерия; воспроизводимость подтверждена прогоном на текущей инфре (staging-песочница
-  8501 / sandbox-проект).
-- **BR-5 (zero-regression)** — на текущем хосте поведение 1:1: все новые параметры имеют дефолты =
-  сегодняшним значениям; пустой/неизменённый `.env` даёт байт-в-байт текущее поведение; полный
-  `pytest tests/ -q` зелёный.
-- **BR-6 (анти-регресс)** — возврат хост-хардкода в `src/**` ломает CI: структурный тест
-  сканирует код (вне комментариев/докстрингов) на запрещённые литералы.
-- **BR-7 (доки)** — deployment-раздел + карта env + чек-лист секретов + smoke-процедура
-  опубликованы в `docs/operations/`; `CHANGELOG.md` обновлён (правило агентов №2).
-
-## 5. Нефункциональные требования (NFR)
-
-- **NFR-1 (self-hosting safety)** — задача не перезапускает и не роняет прод-контейнер
-  `orchestrator`; правки `docker-compose.yml`/`Dockerfile` инертны до следующего штатного деплоя
-  через конвейер (staging 8501 → Confirm Deploy). Никаких push/force-push в `main` мимо PR.
-- **NFR-2 (обратимость)** — «kill-switch природа» параметризации: отсутствие новых env-переменных
-  = текущее поведение. Отдельный функциональный kill-switch не требуется — дефолты и есть откат.
-- **NFR-3 (секреты вне гита)** — реальные значения только в `.env`/`.env.staging` на хосте
-  (правило агентов №8); в гит попадают только шаблоны/плейсхолдеры; генератор секретов никогда не
-  перезаписывает существующий `.env` молча.
-- **NFR-4 (инварианты соседних задач, правило №9)** — параметризация не ослабляет зафиксированные
-  инварианты: ORCH-058 «freshness-путь целится ТОЛЬКО в staging, никогда в прод 8500»; ORCH-040
-  «uid 1000 + group_add 999 (МИНА 1 — не удалять) + HOME согласован с маунтами»; INV-4 «мерж только
-  через Gitea PR-merge API». Затронутые маркеры читаются перед правкой.
-- **NFR-5 (стабильность анти-регресс теста)** — grep-тест детерминирован и не флапает: судит код,
-  исключает комментарии/докстринги/`tests/**`/`docs/**`; список запрещённых литералов
-  централизован в самом тесте.
-- **NFR-6 (конвейер не трогаем)** — `STAGE_TRANSITIONS`, состав `QG_CHECKS`, семантика `check_*`,
-  machine-verdict ключи, схема БД — байт-в-байт прежние.
-
-## 6. Допущения и ограничения
-
-- Целевой хост тиража: Linux + Docker + Compose; Plane и Gitea доступны (для Типа A — донастройка
-  по инструкции Lite-задачи; их URL/токены подаются через env). Claude CLI присутствует на хосте
-  (пути маунтов параметризуются).
-- Тираж — **single-tenant**: один инстанс платформы на заказчика; общая мультитенантная топология
-  вне объёма.
-- Имя self-hosting репо платформы (`orchestrator`) — платформенная конвенция; делать ли его
-  конфигурируемым (`SELF_HOSTING_REPO`) — решение архитектора (см. `02-trz.md` §3.4, вопрос А-2).
-- Встроенный fallback-реестр проектов (`src/projects.py::_DEFAULT_PROJECTS`) содержит UUID'ы Plane
-  текущего хоста; на новом хосте обязателен `ORCH_PROJECTS_JSON` — фиксируется в чек-листе, сами
-  UUID'ы в дефолте безвредны (не сматчатся) и остаются как документированный fallback.
-- Историческая документация и комментарии кода могут упоминать `mva154`/пути — это не хардкоды
-  поведения и аудитом кода не считаются.
-
-## 7. Критерии успеха
-
-Платформа разворачивается на чужой инфре **без правки кода** — только env/конфиг; секреты
-выпускаются заново по чек-листу; smoke-прогон даёт явный PASS; на текущем хосте — ноль изменений
-поведения и зелёный полный регресс. Детальные условия PASS/FAIL — `03-acceptance-criteria.md`
-(AC-1…AC-8); прослеживаемость BR ↔ AC — в сводной матрице там же.
-
-## 8. Риски
-
-Кратко (детально — `10-tech-risks.md`, заполняет архитектор):
-
-- **Р-1: скрытый регресс при параметризации горячих путей** (`launcher` env агентов, compose
-  volumes) — митигируется дефолтами = текущим значениям + полным регрессом + staging-прогоном.
-- **Р-2: ослабление инварианта ORCH-058** при конфигуризации staging-порта (`_STAGING_PORT`) —
-  митигируется guard-условием «staging-порт ≠ прод-порт» и решением архитектора (возможно,
-  оставить константой с обоснованием).
-- **Р-3: флап анти-регресс grep-теста** (ложные срабатывания на комментарии) — митигируется
-  правилами исключений NFR-5.
-- **Р-4: неполный аудит** (пропущенный хардкод всплывает на первом реальном тираже) — митигируется
-  нормативным реестром §3.1 ТЗ + smoke-процедурой как последней линией обнаружения.
-- **Р-5: расползание скоупа в Lite/Bundled** — митигируется явным «вне объёма» §2.

docs/work-items/ORCH-101/02-trz.md

@@ -1,253 +0,0 @@
----
-work_item: ORCH-101
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 02 — ТЗ (TRZ): ORCH-101 — ORCH-10-common: расхардкод + секреты + smoke (фундамент тиража)
-
-Work Item: **ORCH-101** · Repo: **orchestrator** · Стадия: analysis
-
-> ТЗ описывает **что** должно измениться и **где** (модули/контракты/артефакты), выведено из BRD и
-> фактического кода (аудит выполнен по репо на ветке задачи). **Как** (точные имена новых
-> конфиг-ключей, механика генератора секретов, форма smoke-скрипта) — решает архитектор в `06-adr/`.
-
----
-
-## 1. Сводка изменения
-
-Три слоя одного фундамента тиража (эпик ORCH-10, оба типа A/B):
-
-1. **Расхардкод:** все хост-специфичные значения, которые сегодня **обходят конфиг** (зашиты в код
-   `src/**`, в `docker-compose.yml`, `Dockerfile`, `scripts/orchestrator-deploy-hook.sh`),
-   переводятся на чтение из `Settings` (env `ORCH_*`) / compose-интерполяцию `${VAR:-default}` /
-   `ARG` / env-override — **с дефолтами, равными текущим боевым значениям** (zero-regression).
-   Нормативный реестр находок — §3.1 (результат аудита всего репо).
-2. **Секреты:** механизм выпуска **нового** комплекта секретов на новом хосте (генерация
-   webhook-секретов + чек-лист внешних токенов) + полнота `.env.example`.
-3. **Smoke:** документированная воспроизводимая процедура «тестовый проект + задача → конвейер
-   доехал» с PASS/FAIL-критериями (+ анти-регресс grep-тест против возврата хардкодов).
-
-Конвейер (`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/verdict-ключи/схема БД) — не меняется.
-
----
-
-## 2. Задействованные модули / пути
-
-| Путь | Действие |
-|------|----------|
-| `src/config.py` | изменить: новые `Settings`-ключи (HOME агент-процессов, git-идентичность акторов, внешний Gitea-URL уже есть — `gitea_public_url`; прочее по §3.1), дефолты = текущим значениям |
-| `src/plane_sync.py` | изменить: `notify_stage_change` — убрать литерал `gitea_base = "http://git.mva154.duckdns.org"` и owner `admin` из путей ссылок → `settings.gitea_public_url` (fallback `gitea_url`) + `settings.gitea_owner` |
-| `src/agents/launcher.py` | изменить: env агент-процесса (×2 места) — `HOME` и git author/committer (`claude-bot@mva154.local`) из конфига |
-| `src/self_deploy.py` | изменить: env detached-процесса — `HOME`, `deploy-finalizer@mva154.local` из конфига |
-| `src/post_deploy.py` | изменить: env монитора — `HOME`, `post-deploy-monitor@mva154.local` из конфига |
-| `src/image_freshness.py` | изменить ИЛИ обосновать: `_STAGING_PORT = 8501` (см. §3.4 А-1, инвариант ORCH-058) |
-| `src/qg/checks.py` | изменить ИЛИ обосновать: `SELF_HOSTING_REPO = "orchestrator"` (см. §3.4 А-2) |
-| `src/fs_normalize.py` | изменить: fallback-подсказку `sudo chown -R 1000:1000 /repos/_wt` строить из `settings` (uid/worktrees_dir) |
-| `src/projects.py` | не менять логику; `_DEFAULT_PROJECTS` остаётся документированным fallback (UUID'ы чужого Plane безвредны); фиксация в чек-листе «на новом хосте обязателен `ORCH_PROJECTS_JSON`» |
-| `watchdog/config.py` | проверить/синхронизировать: уже env-driven (`WATCHDOG_*`); дефолт `http://127.0.0.1:8500/metrics` согласовать с параметризацией прод-порта |
-| `docker-compose.yml` | изменить: интерполяция `${VAR:-default}` для всех хост-значений (§3.1 B) |
-| `Dockerfile` | изменить: `ARG` для uid/gid/username/home; CMD-порт — по решению архитектора (§3.4 А-3) |
-| `scripts/orchestrator-deploy-hook.sh` | изменить: `REPO=/home/slin/repos/orchestrator` → env-override `REPO="${REPO:-…}"` |
-| `scripts/` (новый) | создать: генератор секретов и/или smoke-обвязка — форма за архитектором (§3.2, §3.3) |
-| `.env.example` | изменить: новые ключи, секции секретов с плейсхолдерами, чек-лист «что заполнить» |
-| `.env.staging.example` | изменить: согласовать с новыми ключами (при необходимости) |
-| `tests/test_no_host_hardcodes.py` (новый) | создать: структурный анти-регресс grep-тест (FR-8) |
-| `tests/` (новые) | создать: тесты параметризации/секретов/smoke по `04-test-plan.yaml` |
-| `docs/operations/` | создать deployment-раздел тиража (предложение: `REPLICATION.md`; имя финализирует архитектор) + обновить карту env в `INFRA.md` |
-| `CHANGELOG.md`, `CLAUDE.md`, `README.md` | изменить: запись изменения; паспорт/обзорные доки — по фактическому объёму (правило агентов №2/№6) |
-
----
-
-## 3. Функциональные требования
-
-### FR-1 — Нормативный реестр хардкодов (результат аудита) и их устранение
-
-Привязка: BR-1, BR-2. Аудит выполнен по всему репо (grep по классам: IP/hostname, пути, порты,
-gid/uid, URL, идентичности). Реестр ниже **нормативен**: developer закрывает каждую строку;
-расхождение «нашёл ещё» — дополняет реестр в PR, а не игнорирует.
-
-#### 3.1. Реестр
-
-**A. `src/**` / `watchdog/**` — код, обходящий конфиг (блокеры AC-1):**
-
-| # | Файл:строка | Хардкод | Требование |
-|---|---|---|---|
-| A1 | `src/plane_sync.py:1064` | `gitea_base = "http://git.mva154.duckdns.org"` в `notify_stage_change` + owner `admin` в построении ссылок Branch/PR | читать `settings.gitea_public_url` (fallback `settings.gitea_url`; loopback-семантика — как в `notifications._build_plane_issue_link`) + `settings.gitea_owner`; никаких новых ключей не требуется |
-| A2 | `src/agents/launcher.py:594, 825` | `"HOME": "/home/slin"`; `GIT_AUTHOR/COMMITTER_EMAIL: claude-bot@mva154.local` (×2 места) | HOME и git-идентичность из конфига (новые ключи, дефолты = текущим значениям) |
-| A3 | `src/self_deploy.py:332–336` | `"HOME": "/home/slin"`; `deploy-finalizer@mva154.local` | то же (единый источник с A2; имя актора может остаться per-actor) |
-| A4 | `src/post_deploy.py:575–579` | `"HOME": "/home/slin"`; `post-deploy-monitor@mva154.local` | то же |
-| A5 | `src/image_freshness.py:61` | `_STAGING_PORT = 8501` (модульная константа; намеренный анти-prod-инвариант ORCH-058 AC-9) | конфигуризовать с дефолтом 8501 **с сохранением инварианта** (guard «staging-порт ≠ прод-порт») ИЛИ оставить константой с явным обоснованием в ADR — решение архитектора (§3.4 А-1) |
-| A6 | `src/qg/checks.py:517` | `SELF_HOSTING_REPO = "orchestrator"` (узел: на него опираются все `*_repos`-leaf'ы «empty CSV → self-hosting only») | конфиг-ключ с дефолтом `orchestrator` ИЛИ нормативная платформенная константа («репо платформы в тираже обязан называться `orchestrator`», фиксируется в deployment-доке) — решение архитектора (§3.4 А-2) |
-| A7 | `src/fs_normalize.py:539` | fallback-строка подсказки `sudo chown -R 1000:1000 /repos/_wt` | строить из `settings.fs_target_uid` / `settings.worktrees_dir` (соседние строки 533–535 уже так делают) |
-| A8 | `src/disk_watchdog.py:95` | fallback `["/repos", "/app/data"]` — зеркало дефолта `settings.disk_monitor_paths` | допустимое config-backed зеркало; не блокер. Требование: значения остаются синхронными с конфиг-дефолтом (одна точка истины желательна — на усмотрение архитектора) |
-| A9 | `src/projects.py:42–55` | `_DEFAULT_PROJECTS`: UUID'ы Plane текущего хоста | НЕ блокер (документированный fallback «out of the box», чужие UUID не сматчатся). Требование: чек-лист тиража обязывает задать `ORCH_PROJECTS_JSON` |
-| A10 | `watchdog/config.py:100,144` | дефолт `http://127.0.0.1:8500/metrics` | уже env-driven (`WATCHDOG_METRICS_URL`); дефолт легитимен; согласовать с А-3 (прод-порт), если тот станет параметром |
-
-> Паттерн `getattr(settings, "x", <литерал>)` (A7/A8 и др.) — **config-backed fallback**, не
-> хардкод-блокер: значение управляется конфигом. Блокер — только код, который конфиг **обходит**.
-
-**B. `docker-compose.yml` — хост-специфика (блокеры AC-6):**
-
-| # | Место | Хардкод |
-|---|---|---|
-| B1 | volumes ×3 сервисов | `/home/slin/repos:/repos`(+`:ro`), `/home/slin/.claude`, `/home/slin/.claude.json`, `/home/slin/.orchestrator-ssh:/home/slin/.ssh` |
-| B2 | volumes ×2 сервисов | `/usr/lib/node_modules/@anthropic-ai/claude-code:/opt/claude-code:ro`, `/usr/bin/node:/usr/bin/node:ro` |
-| B3 | `group_add` ×3 | `"999"` (gid docker-группы хоста) |
-| B4 | `user:` ×2 | `"1000:1000"` (uid:gid хоста) |
-| B5 | environment | `ORCH_HOST_REPOS_DIR=/home/slin/repos` ×2, `ORCH_DEPLOY_HOST_REPO_PATH=/home/slin/repos/orchestrator`, `DEPLOY_SSH_USER=slin` ×2, `ORCH_DEPLOY_SSH_USER=slin`, `DEPLOY_HOOK_SCRIPT=/home/slin/bin/enduro-deploy-hook.sh` ×2 (legacy enduro) |
-| B6 | `orchestrator-staging.command` | порт `8501` |
-
-Требование: compose-интерполяция `${VAR:-default}` (источник — `.env`, штатный механизм Compose);
-`docker compose config` без заданных переменных резолвится в текущие значения 1:1. Целевая
-семантика «HOME внутри контейнера согласован с маунтами `.claude`/`.ssh` и `useradd` Dockerfile»
-(инвариант ORCH-040) сохраняется как согласованная группа переменных.
-
-**C. `Dockerfile`:**
-
-| # | Место | Хардкод |
-|---|---|---|
-| C1 | `useradd -u 1000 -g 1000 -m -d /home/slin -s /bin/bash slin` | uid/gid/home/username |
-| C2 | `CMD … --port 8500` | прод-порт |
-
-Требование: C1 → `ARG` с дефолтами (1000/1000//home/slin/slin). C2 — по решению архитектора
-(§3.4 А-3): порт уже переопределяем через compose `command:`; допустимо оставить CMD-дефолт 8500.
-
-**D. `scripts/`:**
-
-| # | Место | Хардкод |
-|---|---|---|
-| D1 | `orchestrator-deploy-hook.sh:38` | `REPO=/home/slin/repos/orchestrator` (единственный непараметризованный путь скрипта; остальное уже env-override) |
-
-Требование: `REPO="${REPO:-/home/slin/repos/orchestrator}"` (паттерн остальных переменных скрипта).
-`scripts/staging_check.py` — уже env-driven (`ORCH_PLANE_API_URL`/`ORCH_GITEA_URL`/`--base-url`),
-изменений не требует.
-
-**E. Уже параметризовано (НЕ трогать, фиксация аудита):** дефолты `src/config.py`
-(`plane_api_url:8091`, `gitea_url:3000`, `repos_dir`, `host_repos_dir`, `worktrees_dir`, `runs_dir`,
-`db_path`, `deploy_ssh_user`, `deploy_host_repo_path`, `deploy_prod_target_port:8500`,
-`post_deploy_base_url`, `disk_monitor_paths`, `claude_bin`) — легитимные значения по умолчанию,
-управляемые env; менять их значения запрещено (BR-5).
-
-### FR-2 — Чтение хост-значений из конфига в `src/**`
-
-Привязка: BR-1. Каждый блокер класса A (A1–A4, A7; A5/A6 — по исходу §3.4) читает значение через
-`settings` (существующие либо новые ключи `Settings` с env `ORCH_*`). Требования к новым ключам:
-
-- дефолт = текущее боевое значение (BR-5): `/home/slin`, `claude-bot`, `*@mva154.local`-адреса;
-- описательный комментарий в `config.py` по образцу существующих блоков (назначение + env-имя);
-- ключи отражены в `.env.example` и карте env `INFRA.md`;
-- точные имена ключей и группировка (например, единый `agent_home_dir` + per-actor идентичности
-  или общий email-домен) — решение архитектора; ТЗ фиксирует контракт: **ни один из пяти акторов
-  (агенты CLI ×2 места, self-deploy finalizer, post-deploy monitor, fs-подсказка) не содержит
-  литералов `/home/slin` / `mva154` после изменения**.
-
-### FR-3 — Параметризация инфра-файлов
-
-Привязка: BR-2. Реестр B/C/D закрыт; механика — compose-интерполяция / `ARG` / shell-default.
-Инварианты: ORCH-040 (uid 1000 + `group_add` docker-gid + HOME-согласованность маунтов — группа
-переменных меняется согласованно, «МИНА 1» `group_add` не удаляется), ORCH-058 (staging-сервис
-никогда не резолвится в прод-таргет). Поведение `docker compose config` при пустом окружении —
-эквивалент текущего файла (проверяется тестом TC-06).
-
-### FR-4 — Механизм секретов нового хоста
-
-Привязка: BR-3. Состав:
-
-1. **Инвентаризация** (фиксация аудита): генерируемые локально — `ORCH_PLANE_WEBHOOK_SECRET`,
-   `ORCH_GITEA_WEBHOOK_SECRET`; выпускаемые внешними системами — `ORCH_PLANE_API_TOKEN`,
-   `ORCH_PLANE_BOT_*` (7 шт., опциональны: fallback на `ORCH_PLANE_API_TOKEN`), `ORCH_GITEA_TOKEN`,
-   `ORCH_TELEGRAM_BOT_TOKEN` (+ несекретный `ORCH_TELEGRAM_CHAT_ID`).
-2. **Генерация:** webhook-секреты создаются криптослучайно (стандарт: `secrets`-модуль Python /
-   эквивалент, длина ≥ 32 байт энтропии) на целевом хосте; форма (отдельный
-   `scripts/gen_secrets.py`, режим onboarding-CLI или документированная команда) — решение
-   архитектора. Требования к поведению: повторный запуск даёт другие значения; существующий `.env`
-   никогда не перезаписывается молча (NFR-3); вывод согласован с ключами `.env.example`.
-3. **Чек-лист** в deployment-доке: для каждого секрета — где выпустить (Plane UI/API, Gitea UI,
-   BotFather), куда вписать, как проверить. Явное правило: «боевые секреты текущего хоста не
-   копируются».
-4. **Полнота `.env.example`:** каждый обязательный для старта ключ присутствует (с плейсхолдером
-   или дефолтом), включая новые ключи FR-2/FR-3; секретные значения — только плейсхолдеры.
-
-### FR-5 — Smoke-верификация тиража
-
-Привязка: BR-4. Документированная процедура (deployment-раздел) + опциональная скрипт-обвязка
-(форма — архитектор; кандидаты-кирпичи уже в репо: `scripts/onboard_project.py` `plan/apply/verify`,
-`scripts/staging_check.py`, `GET /health` / `/queue` / `/metrics`):
-
-1. **Шаги:** поднять инстанс (env+секреты заполнены) → `GET /health` ок → завести тестовый
-   проект (onboarding-CLI `verify` или sandbox-проект) → создать тестовую задачу → убедиться, что
-   конвейер «доехал» (задача продвигается по стадиям; минимальный обязательный сигнал — стадия
-   `analysis` отработала и артефакты `01–04` созданы; полный прогон до `done` — расширенный режим).
-2. **Критерии:** каждый шаг имеет явный PASS/FAIL; итог процедуры — однозначный вердикт.
-3. **Воспроизводимость:** процедура прогоняется на текущей инфре (staging-песочница 8501 +
-   sandbox-проект) без нового железа — это и приёмочная проверка AC-3.
-4. **Stateless:** процедура нигде не предполагает перенос данных/БД с боевого хоста.
-
-### FR-6 — Анти-регресс структурный тест
-
-Привязка: BR-6. Новый `tests/test_no_host_hardcodes.py` (образец — `tests/test_agent_prompts_canon.py`):
-
-- сканирует `src/**/*.py` и `watchdog/**/*.py` на запрещённые литералы: `82.22.50.71`,
-  `/home/slin`, `mva154`, `duckdns` (список централизован в тесте; расширяем);
-- судит **код**: строки-комментарии и докстринги исключаются (NFR-5; механика исключения —
-  прагматичная построчная/AST — за developer);
-- `tests/**`, `docs/**`, `.env.example` — вне зоны сканирования;
-- допускает точечный явный allowlist (файл:литерал) с комментарием-обоснованием — пустой на
-  момент сдачи задачи (все блокеры A закрыты).
-
-### FR-7 — Документация
-
-Привязка: BR-7. Deployment-раздел в `docs/operations/` (предложение: `REPLICATION.md`): карта
-новых env-переменных (включая compose-интерполяцию), процедура секретов (FR-4), smoke-процедура
-(FR-5), границы «10-common vs Lite vs Bundled». Обновления: `INFRA.md` (карта env),
-`CHANGELOG.md`; `CLAUDE.md`/`README.md` — по фактическому объёму изменений (правило №2/№6).
-
----
-
-### 3.4. Вопросы архитектору (решаются в `06-adr/`, не в ТЗ)
-
-- **А-1:** `_STAGING_PORT = 8501` (`image_freshness`) — конфиг-ключ с guard'ом «≠ прод-порт» или
-  нормативная константа? Инвариант ORCH-058 AC-9 («никогда не прод 8500») обязан сохраниться.
-- **А-2:** `SELF_HOSTING_REPO = "orchestrator"` — конфиг-ключ или платформенная конвенция тиража
-  (репо платформы всегда `orchestrator`)? На него завязаны все `*_repos`-leaf'ы.
-- **А-3:** CMD-порт Dockerfile (8500) — `ARG` или остаётся (порт уже переопределяем compose
-  `command:`)?
-- **А-4:** форма генератора секретов (отдельный скрипт / режим `onboard_project.py` /
-  документированная команда) и форма smoke (чистый runbook / runbook + скрипт).
-- **А-5:** группировка новых конфиг-ключей FR-2 (единый HOME-ключ + per-actor email'ы vs общий
-  email-домен).
-
----
-
-## 4. Изменения API
-
-Нет. Существующие эндпоинты (`/health`, `/queue`, `/metrics`) переиспользуются smoke-процедурой
-read-only; новые эндпоинты не вводятся.
-
-## 5. Изменения схемы БД
-
-Нет.
-
-## 6. Требования к новым/изменённым QG checks
-
-Нет. `QG_CHECKS`/`check_*`/machine-verdict ключи не меняются. Новый структурный тест (FR-6) —
-обычный pytest: попадает в существующие гейты `check_ci_green`/`check_tests_passed`/merge-gate
-re-test автоматически, без регистрации нового QG.
-
-## 7. Совместимость / регресс
-
-- **Zero-regression (BR-5):** все новые параметры — с дефолтами, равными сегодняшним боевым
-  значениям; пустой/неизменённый `.env` ⇒ байт-в-байт текущее поведение; `docker compose config`
-  без переменных ⇒ эквивалент текущего файла. Полный `pytest tests/ -q` зелёный.
-- **Обратимость (NFR-2):** откат = не задавать новые переменные. Функциональный kill-switch не
-  требуется (дефолты и есть прежнее поведение); вводить новый флаг ради флага запрещено.
-- **Область раската:** изменения инертны для enduro-trails (значения те же); compose/Dockerfile
-  вступают в силу только при следующем штатном деплое через конвейер (staging 8501 → ручной
-  Confirm Deploy) — прод-контейнер в рамках задачи не рестартуется (NFR-1).
-- **Инварианты соседних маркеров (правило №9):** ORCH-040 (uid/gid/HOME/«МИНА 1»), ORCH-058
-  (freshness → только staging), ORCH-036/059 (self-deploy фазы, Confirm Deploy), INV-4 (мерж только
-  через PR-merge API) — сохраняются; соответствующие ADR прочитаны при правке помеченных блоков.

docs/work-items/ORCH-101/03-acceptance-criteria.md

@@ -1,131 +0,0 @@
----
-work_item: ORCH-101
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 03 — Критерии приёмки (Acceptance Criteria): ORCH-101 — ORCH-10-common: расхардкод + секреты + smoke
-
-Work Item: **ORCH-101** · Repo: **orchestrator** · Стадия: analysis
-
-Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL**
-(что считается провалом). Любой машинный/ручной reviewer проверяет их буквально по файлам
-репозитория. AC-1…AC-4 — дословно из бизнес-запроса (уточнены до проверяемости); AC-5…AC-8 —
-детализация скоупа (секреты/инфра/анти-регресс/инварианты).
-
----
-
-## AC-1 — Ноль хардкодов хоста/путей/портов в `src/**`
-
-**Условие:** в коде `src/**` и `watchdog/**` (вне комментариев/докстрингов) нет хост-специфичных
-литералов, обходящих конфиг; всё читается из env/конфига с дефолтами. Проверка — grep-тестом
-(`tests/test_no_host_hardcodes.py`) и ревью по реестру `02-trz.md` §3.1.
-- **PASS:**
-  - блокеры A1–A4, A7 реестра закрыты: `grep -rn "git.mva154.duckdns.org\|/home/slin\|mva154.local" src/ watchdog/` не находит ни одного вхождения в исполняемом коде (докстринги/комментарии — допустимы);
-  - `src/plane_sync.py::notify_stage_change` строит ссылки Branch/PR из `settings.gitea_public_url` (fallback `gitea_url`) и `settings.gitea_owner`;
-  - env-словари акторов (`launcher` ×2, `self_deploy`, `post_deploy`) берут HOME и git-идентичность из `settings`;
-  - A5 (`_STAGING_PORT`) и A6 (`SELF_HOSTING_REPO`) либо конфигуризованы, либо явно обоснованы в ADR задачи как платформенные константы (решение архитектора зафиксировано);
-  - структурный тест `tests/test_no_host_hardcodes.py` существует, его allowlist пуст (или каждая запись обоснована комментарием), тест зелёный.
-- **FAIL:** хотя бы один литерал `82.22.50.71` / `/home/slin` / `mva154` / `duckdns` в исполняемом коде `src/**`/`watchdog/**`; ИЛИ ссылка в Plane-комментарии всё ещё строится от захардкоженного `http://git.mva154.duckdns.org`; ИЛИ A5/A6 не конфигуризованы и не обоснованы в ADR; ИЛИ анти-регресс тест отсутствует/красный.
-
----
-
-## AC-2 — Без регресса: на текущем хосте поведение 1:1
-
-**Условие:** дефолты всех новых параметров равны текущим боевым значениям; pytest зелёный.
-- **PASS:**
-  - каждый новый `Settings`-ключ / compose-переменная / `ARG` / shell-default имеет дефолт, равный значению, зашитому до задачи (`/home/slin`, `claude-bot@mva154.local`-адреса, gid 999, uid 1000, порты 8500/8501, пути node/claude-code и т.д.);
-  - `docker compose config` без заданных переменных окружения резолвится в эквивалент текущей конфигурации (volumes/user/group_add/environment/command совпадают по значениям);
-  - значения существующих дефолтов `src/config.py` (реестр §3.1 E) не изменены;
-  - полный `pytest tests/ -q` зелёный;
-  - `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict ключи / схема БД — без изменений (диф не затрагивает их семантику).
-- **FAIL:** хотя бы один дефолт отличается от текущего боевого значения; ИЛИ `docker compose config` при пустом окружении даёт иную эффективную конфигурацию; ИЛИ любой существующий тест красный; ИЛИ диф меняет машину стадий/реестр QG/схему БД.
-
----
-
-## AC-3 — Smoke-процедура задокументирована и воспроизводима
-
-**Условие:** существует документированная процедура «развёрнутый инстанс → тестовый проект +
-задача → конвейер доехал» с явными PASS/FAIL-критериями; воспроизводимость подтверждена.
-- **PASS:**
-  - в `docs/operations/` есть раздел/документ (предложение ТЗ: `REPLICATION.md`) с пошаговой smoke-процедурой: health-check инстанса → тестовый проект → тестовая задача → подтверждение продвижения конвейера (минимум: `analysis` отработала, артефакты `01–04` созданы; расширенный режим — до `done`);
-  - каждый шаг имеет явный ожидаемый результат (PASS/FAIL), итог — однозначный вердикт;
-  - процедура не требует переноса данных/секретов с боевого хоста (stateless);
-  - воспроизводимость подтверждена хотя бы одним прогоном на текущей инфре (staging-песочница 8501 / sandbox-проект) — результат зафиксирован в артефактах задачи (например, `13-test-report.md` / `15-staging-log.md`);
-  - если введена скрипт-обвязка (`scripts/…`) — она запускается (`--help`/dry-run без ошибок) и покрыта тестом из `04-test-plan.yaml`.
-- **FAIL:** процедуры нет; ИЛИ шаги без явных критериев («посмотреть, что всё ок»); ИЛИ процедура требует копирования боевых данных/секретов; ИЛИ заявленный прогон не зафиксирован; ИЛИ скрипт-обвязка падает на запуске.
-
----
-
-## AC-4 — Доки (deployment-раздел) + CHANGELOG
-
-**Условие:** документация обновлена в том же PR (правило агентов №2; reviewer проверяет — №6).
-- **PASS:**
-  - deployment-раздел (см. AC-3) дополнительно содержит: карту всех новых env-переменных (имя, назначение, дефолт), процедуру/чек-лист секретов (см. AC-5), границы «10-common vs Lite vs Bundled»;
-  - карта переменных окружения в `docs/operations/INFRA.md` дополнена новыми ключами;
-  - `CHANGELOG.md` содержит запись ORCH-101;
-  - `CLAUDE.md`/`README.md` обновлены, если фактический объём изменений того требует (новые операторские способности/ограничения).
-- **FAIL:** новый env-ключ отсутствует в карте env; ИЛИ нет записи в `CHANGELOG.md`; ИЛИ deployment-раздел не покрывает секреты/smoke; ИЛИ README выдаёт решённое за открытое (правило №6).
-
----
-
-## AC-5 — Секреты: генерация новых, не копирование боевых
-
-**Условие:** механизм выпуска нового комплекта секретов на новом хосте существует и безопасен.
-- **PASS:**
-  - webhook-секреты (`ORCH_PLANE_WEBHOOK_SECRET`, `ORCH_GITEA_WEBHOOK_SECRET`) генерируются криптослучайно (≥ 32 байт энтропии; повторный запуск даёт другие значения);
-  - механизм никогда не перезаписывает существующий `.env` молча;
-  - чек-лист перечисляет все внешние токены (`ORCH_PLANE_API_TOKEN`, `ORCH_PLANE_BOT_*`, `ORCH_GITEA_TOKEN`, `ORCH_TELEGRAM_BOT_TOKEN`) с указанием, где их выпустить и куда вписать; явно сказано «боевые секреты не копируются»;
-  - `.env.example` покрывает 100% ключей, обязательных для старта (включая новые из AC-1/AC-2), секретные значения — только плейсхолдеры; реальные секреты в гит не попадают (`.gitleaks`/security-гейт зелёный);
-  - `.env.staging.example` согласован (если затронут).
-- **FAIL:** секрет генерируется детерминированно/слабо; ИЛИ запуск механизма затирает существующий `.env`; ИЛИ в `.env.example` отсутствует обязательный ключ; ИЛИ в гит закоммичено реальное секретное значение; ИЛИ процедура предписывает копирование боевого секрета.
-
----
-
-## AC-6 — Инфра-файлы параметризованы
-
-**Условие:** `docker-compose.yml`, `Dockerfile`, `scripts/orchestrator-deploy-hook.sh` не требуют
-правки под новый хост — только переменные.
-- **PASS:**
-  - реестр §3.1 B/C/D закрыт: пути `/home/slin/...`, gid `999`, uid `1000:1000`, node/claude-code-пути, ssh-user, staging-порт в `command:`, `REPO=` в deploy-hook — параметризованы (`${VAR:-default}` / `ARG` / `"${REPO:-…}"`) с дефолтами = текущим значениям;
-  - связка «uid/gid/HOME/маунты `.claude`+`.ssh`/`useradd`» меняется согласованной группой переменных (инвариант ORCH-040 сохранён, `group_add` docker-gid не удалён);
-  - структурный тест параметризации (TC-06/TC-12 из `04-test-plan.yaml`) зелёный.
-- **FAIL:** хотя бы одно значение реестра B/C/D осталось непараметризованным; ИЛИ группа ORCH-040 рассогласована (HOME ≠ маунт-таргеты при дефолтах); ИЛИ `group_add` удалён; ИЛИ структурный тест красный.
-
----
-
-## AC-7 — Анти-регресс защита от возврата хардкодов
-
-**Условие:** возврат хост-хардкода в `src/**` ломает CI.
-- **PASS:** `tests/test_no_host_hardcodes.py` существует; сканирует `src/**`+`watchdog/**` на централизованный список запрещённых литералов (минимум: `82.22.50.71`, `/home/slin`, `mva154`, `duckdns`); исключает комментарии/докстринги/`tests/**`/`docs/**`; детерминирован (повторные прогоны стабильны); демонстрационно ловит подсадку литерала (негативная самопроверка в самом тесте или в тестах теста).
-- **FAIL:** тест отсутствует; ИЛИ не ловит подсаженный в код литерал из списка; ИЛИ флапает; ИЛИ список литералов размазан по нескольким местам без единой точки правки.
-
----
-
-## AC-8 — Self-hosting безопасность и инварианты соседних задач
-
-**Условие:** задача не дестабилизирует общий прод и не ослабляет зафиксированные инварианты.
-- **PASS:**
-  - в рамках задачи прод-контейнер `orchestrator` не перезапускается; прод-деплой — только штатно (staging 8501 → ручной `Confirm Deploy`);
-  - инвариант ORCH-058 сохранён: freshness/staging-путь не может быть переконфигурирован в прод-таргет (guard «staging-порт ≠ прод-порт» при конфигуризации A5 — либо A5 остался константой по ADR);
-  - INV-4 сохранён (никаких push/force-push в `main` мимо PR-merge API);
-  - маркеры `ORCH-NNN` в правленых блоках сохранены/обновлены корректно (правило №9).
-- **FAIL:** диф содержит рестарт/останов прод-контейнера вне штатного деплой-пути; ИЛИ конфигурацией можно нацелить staging-rebuild на прод-порт; ИЛИ нарушен INV-4; ИЛИ правка помеченного блока стёрла инвариант соседнего ADR.
-
----
-
-## Сводная матрица AC ↔ BR/FR
-
-| AC | Покрывает |
-|----|-----------|
-| AC-1 | BR-1 / FR-1, FR-2, FR-6 |
-| AC-2 | BR-5 / FR-1 (реестр E), FR-2, FR-3, NFR-6 |
-| AC-3 | BR-4 / FR-5 |
-| AC-4 | BR-7 / FR-7 |
-| AC-5 | BR-3 / FR-4, NFR-3 |
-| AC-6 | BR-2 / FR-3, NFR-4 |
-| AC-7 | BR-6 / FR-6, NFR-5 |
-| AC-8 | NFR-1, NFR-2, NFR-4 / FR-3 |

docs/work-items/ORCH-101/04-test-plan.yaml

@@ -1,146 +0,0 @@
-work_item: ORCH-101
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
-title: "ORCH-10-common: расхардкод + секреты + smoke — план тестов"
-framework: pytest
-scope: >
-  Покрывается: расхардкод src/**+watchdog/** (чтение хост-значений из Settings),
-  параметризация docker-compose.yml/Dockerfile/deploy-hook (структурные проверки),
-  полнота .env.example, поведение генератора секретов, запускаемость smoke-обвязки,
-  анти-регресс grep-тест и его негативная самопроверка, zero-regression (полный
-  регресс tests/). Вне покрытия: реальный e2e-тираж на новом железе (заменён
-  воспроизводимым прогоном smoke-процедуры на staging-песочнице 8501 — AC-3),
-  задачи Lite/Bundled эпика ORCH-10, перенос данных (stateless по решению 10.06).
-notes: >
-  Имена новых тест-модулей — предложение analyst; developer может переименовать,
-  сохранив покрытие TC. Дефолты всех новых параметров обязаны равняться текущим
-  боевым значениям (AC-2) — тесты фиксируют это явно. Анти-регресс тест судит
-  исполняемый код (комментарии/докстринги исключены) — образец структурных тестов:
-  tests/test_agent_prompts_canon.py. Полный регресс tests/ должен оставаться
-  зелёным; STAGE_TRANSITIONS/QG_CHECKS/check_*/machine-verdict не меняются —
-  новые тесты входят в существующие гейты (check_ci_green) автоматически.
-
-tests:
-  - id: TC-01
-    type: unit
-    description: >
-      Анти-регресс скан: в исполняемом коде src/** и watchdog/** нет запрещённых
-      литералов (82.22.50.71, /home/slin, mva154, duckdns); комментарии/докстринги
-      исключаются; список литералов централизован; allowlist пуст либо каждая
-      запись обоснована (AC-1, AC-7 / FR-6).
-    module: tests/test_no_host_hardcodes.py
-    expected: PASS
-
-  - id: TC-02
-    type: unit
-    description: >
-      Негативная самопроверка сканера: подсаженный во временный/фиктивный модуль
-      запрещённый литерал детектируется (сканер реально ловит, не вечно-зелёный)
-      (AC-7 / FR-6, NFR-5).
-    module: tests/test_no_host_hardcodes.py
-    expected: PASS
-
-  - id: TC-03
-    type: unit
-    description: >
-      plane_sync.notify_stage_change строит ссылки Branch/PR из
-      settings.gitea_public_url (fallback gitea_url) + settings.gitea_owner;
-      литерал git.mva154.duckdns.org и owner admin из кода удалены; при
-      переопределённых настройках ссылка меняется соответственно (monkeypatch,
-      без сети) (AC-1 / FR-1 A1, FR-2).
-    module: tests/test_host_config_keys.py
-    expected: PASS
-
-  - id: TC-04
-    type: unit
-    description: >
-      Env агент-процесса в agents/launcher (оба места запуска): HOME и
-      GIT_AUTHOR/COMMITTER_NAME/EMAIL берутся из settings; дефолты равны прежним
-      значениям (/home/slin, claude-bot@mva154.local); переопределение env-ключей
-      меняет словарь окружения (AC-1, AC-2 / FR-1 A2, FR-2).
-    module: tests/test_host_config_keys.py
-    expected: PASS
-
-  - id: TC-05
-    type: unit
-    description: >
-      Env self_deploy (deploy-finalizer) и post_deploy (monitor): HOME и
-      git-идентичность из settings, дефолты = прежним значениям; литералы
-      /home/slin и *@mva154.local из кода удалены (AC-1, AC-2 / FR-1 A3–A4, FR-2).
-    module: tests/test_host_config_keys.py
-    expected: PASS
-
-  - id: TC-06
-    type: unit
-    description: >
-      Структурная проверка docker-compose.yml: хост-значения реестра ТЗ §3.1 B
-      (пути /home/slin/*, node/claude-code-пути, gid 999, uid 1000:1000, ssh-user,
-      staging-порт в command) выражены интерполяцией ${VAR:-default}, и дефолты
-      равны текущим значениям; group_add docker-gid присутствует во всех трёх
-      сервисах (инвариант ORCH-040 «МИНА 1») (AC-2, AC-6 / FR-3).
-    module: tests/test_infra_parametrization.py
-    expected: PASS
-
-  - id: TC-07
-    type: unit
-    description: >
-      Структурная проверка Dockerfile: uid/gid/username/home параметризованы через
-      ARG с дефолтами 1000/1000/slin//home/slin; решение по CMD-порту соответствует
-      ADR задачи (ARG либо обоснованный дефолт 8500) (AC-2, AC-6 / FR-3, §3.4 А-3).
-    module: tests/test_infra_parametrization.py
-    expected: PASS
-
-  - id: TC-08
-    type: unit
-    description: >
-      Полнота .env.example: каждый обязательный для старта ключ присутствует,
-      включая ВСЕ новые ключи FR-2/FR-3 (сверка с Settings.model_fields по
-      выбранному архитектором контракту); секретные ключи содержат только
-      плейсхолдеры, не реальные значения; deploy-hook принимает REPO через
-      env-override (AC-5, AC-6 / FR-1 D1, FR-4.4).
-    module: tests/test_infra_parametrization.py
-    expected: PASS
-
-  - id: TC-09
-    type: unit
-    description: >
-      Генератор секретов: два запуска дают различные значения; длина/энтропия
-      webhook-секретов >= 32 байт; существующий .env никогда не перезаписывается
-      молча (запуск при существующем файле -> отказ/явное подтверждение);
-      вывод согласован с ключами .env.example (AC-5 / FR-4, NFR-3).
-    module: tests/test_secrets_gen.py
-    expected: PASS
-
-  - id: TC-10
-    type: integration
-    description: >
-      Smoke-обвязка и процедура: deployment-док с пошаговой smoke-процедурой
-      существует и содержит явные PASS/FAIL-критерии каждого шага; если введён
-      скрипт — он запускается без ошибок в безопасном режиме (--help/dry-run, без
-      сети/LLM-расходов); карта env в INFRA.md дополнена; CHANGELOG.md содержит
-      запись ORCH-101 (AC-3, AC-4 / FR-5, FR-7).
-    module: tests/test_replication_smoke.py
-    expected: PASS
-
-  - id: TC-11
-    type: unit
-    description: >
-      Инвариант ORCH-058 при исходе А-1: если staging-порт стал конфигуром —
-      дефолт 8501, guard «staging-порт != прод-порт» отвергает совпадение
-      (freshness-путь невозможно нацелить на прод); если остался константой —
-      тест фиксирует константу 8501 и наличие обоснования в ADR задачи
-      (AC-8 / FR-1 A5, NFR-4).
-    module: tests/test_host_config_keys.py
-    expected: PASS
-
-  - id: TC-12
-    type: integration
-    description: >
-      Полный регресс: pytest tests/ -q зелёный на дефолтной конфигурации (пустой
-      env) — поведение платформы на текущем хосте 1:1; существующие тесты не
-      правились под задачу (кроме согласованных структурных) (AC-2 / BR-5, NFR-6).
-    module: tests/
-    expected: PASS

docs/work-items/ORCH-101/06-adr/ADR-001-host-parametrization-secrets-smoke.md

@@ -1,374 +0,0 @@
----
-work_item: ORCH-101
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# ADR-001: Параметризация хоста + секреты нового хоста + smoke-верификация (фундамент тиража 10-common)
-
-Work Item: **ORCH-101** — ORCH-10-common: расхардкод + секреты + smoke
-Стадия: **architecture**
-Сквозная регистрация: **`docs/architecture/adr/adr-0036-replication-foundation-host-parametrization.md`**
-(решение кросс-каттинговое: задаёт платформенные конвенции тиража и трогает блоки с маркерами
-ORCH-036/040/058 — по `docs/_standards/TRACEABILITY.md` агрегируется сводным сквозным ADR).
-
-## Статус
-Proposed
-
-## Контекст
-
-Эпик ORCH-10 (D5.3 «Масштаб») требует разворачивать платформу на чужой инфре **без правки кода** —
-двумя типами тиража (A Lite / B Bundled), оба stateless. Сегодня платформа прибита к `mva154`:
-часть значений **обходит конфиг**. Аудит стадии analysis (нормативный реестр — `02-trz.md` §3.1)
-перепроверен мной по коду ветки (`grep` всех запрещённых классов по `src/**`+`watchdog/**`):
-
-- **Код-блокеры ровно четыре:** A1 `plane_sync.py:1064` (`gitea_base = "http://git.mva154.duckdns.org"`
-  + owner `admin` в ссылках), A2 `agents/launcher.py:594,825` (HOME + git-идентичность ×2 места),
-  A3 `self_deploy.py:332–336`, A4 `post_deploy.py:575–579` (то же у finalizer/monitor).
-- **Все остальные вхождения** `82.22.50.71|/home/slin|mva154|duckdns` в `src/**`/`watchdog/**` —
-  комментарии/докстринги (`disk_watchdog.py:3,80`, `build_cache_pruner.py:3`, `fs_normalize.py:7`,
-  `config.py:469`) либо **легитимные конфиг-дефолты** (`config.py:48,201` — реестр E, BR-1).
-- A7 (`fs_normalize.py::healing_command`) **уже config-backed в основном пути** (строит из
-  `_resolve_target_uid`/`settings.worktrees_dir`); литерал остался только в `except`-ветке
-  never-raise (см. D10).
-- Инфра-файлы: `docker-compose.yml` (реестр B1–B6), `Dockerfile` (C1–C2),
-  `scripts/orchestrator-deploy-hook.sh:38` (D1 — единственная непараметризованная строка скрипта;
-  критично: хук **безусловно перезаписывает** `REPO=`, поэтому даже корректный env инвокера сегодня
-  игнорируется).
-- Секретов «для нового хоста» нет (общий webhook-secret = чужой хост шлёт нам валидные вебхуки);
-  smoke-процедуры тиража нет.
-
-Сопутствующие инварианты, которые НЕЛЬЗЯ ослабить (правило №9, ADR прочитаны):
-**ORCH-040** (adr-0005: uid 1000 + `group_add: ["999"]` «МИНА 1» + HOME согласован с маунтами),
-**ORCH-058** (adr-0008: freshness-путь целится ТОЛЬКО в staging, explicit-pass таргета, INV-FRESH),
-**ORCH-036** (adr-0007: exit-code контракт хука 0/1/2, detached Phase B), **INV-4** (мерж только
-через Gitea PR-merge API).
-
-## Решение
-
-### Сводка
-
-Три слоя одного фундамента. (1) **Расхардкод**: четыре код-блокера переводятся на `Settings`
-(три новых ключа + два существующих), инфра-файлы — на compose-интерполяцию/`ARG`/env-override;
-**каждый дефолт равен боевому значению** → отсутствие новых переменных = байт-в-байт текущее
-поведение (kill-switch-природа, NFR-2; отдельный флаг не вводится). (2) **Секреты**: новый
-stdlib-скрипт `scripts/gen_secrets.py` (криптослучайные webhook-секреты, печать по умолчанию,
-никогда не перезаписывает `.env` молча) + чек-лист внешних токенов. (3) **Smoke**: чистый runbook
-`docs/operations/REPLICATION.md` из существующих кирпичей (`/health`, `/queue`, `/metrics`,
-`onboard_project.py`, sandbox-задача), без нового скрипта. Анти-регресс — структурный сканер
-`tests/test_no_host_hardcodes.py`. Конвейер (`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/
-machine-verdict/схема БД) — байт-в-байт не тронут (NFR-6).
-
-### D1 — Принцип параметризации: «дефолт = боевое значение», механизм по слоям
-
-| Слой | Механизм | Канон дефолта |
-|------|----------|---------------|
-| `src/**`, `watchdog/**` | ключи `Settings` (env `ORCH_*`) / `watchdog.Config` (`WATCHDOG_*`) | `src/config.py` / `watchdog/config.py` — **единственные легитимные места** хост-литералов в коде (BR-1) |
-| `docker-compose.yml` | интерполяция `${VAR:-default}` | дефолт в самом файле = текущее значение |
-| `Dockerfile` | build `ARG` (+ wiring через compose `build.args`) | дефолт `ARG` = текущее значение |
-| `scripts/orchestrator-deploy-hook.sh` | `"${VAR:-default}"` (паттерн остальных переменных хука) | дефолт = текущее значение |
-
-**Правило одного имени:** если значение нужно и контейнеру (pydantic), и compose-интерполяции —
-используется **одно** env-имя (например `ORCH_AGENT_HOME_DIR`, `ORCH_STAGING_PORT`): pydantic
-читает его из `env_file`, compose — из `.env`/shell. Два имени для одного факта запрещены.
-
-**Источник интерполяции (важно, фиксируется в REPLICATION.md):** compose резолвит `${VAR}` из
-`.env` проекта/shell-окружения, **НЕ** из `env_file` сервиса — `.env.staging` на интерполяцию не
-влияет. Для single-host тиража это штатно: интерполяционные значения живут в `.env`.
-
-Привязка: BR-1, BR-2, BR-5, NFR-2 / FR-1, FR-2, FR-3. Проверка: AC-1, AC-2, AC-6 (TC-01…TC-08).
-
-### D2 — Новые `Settings`-ключи и группировка акторских env (вопрос А-5)
-
-Выбран вариант **«единый HOME + общий email-домен + одно агентское имя»** (3 ключа), против
-6+ per-actor ключей:
-
-| Ключ | env | Дефолт | Потребители |
-|------|-----|--------|-------------|
-| `agent_home_dir` | `ORCH_AGENT_HOME_DIR` | `/home/slin` | `HOME` всех 4 акторских env-словарей: `launcher` (×2 места — Popen агента и git commit/push), `self_deploy.write_deploy_log`, `post_deploy.write_post_deploy_log`; + compose mount-таргеты и `ARG APP_HOME` (D5/D6) |
-| `agent_git_name` | `ORCH_AGENT_GIT_NAME` | `claude-bot` | `GIT_AUTHOR/COMMITTER_NAME` агентов в `launcher` (×2) — customer-visible идентичность коммитов |
-| `git_email_domain` | `ORCH_GIT_EMAIL_DOMAIN` | `mva154.local` | домен email всех трёх акторов |
-
-**Контракт идентичностей:** email строится как `f"{name}@{settings.git_email_domain}"`, где
-`name` = `settings.agent_git_name` для агентов (launcher) и **платформенные литералы**
-`deploy-finalizer` / `post-deploy-monitor` для системных акторов (`self_deploy` / `post_deploy`) —
-имена системных акторов не хост-специфичны, различимость их коммитов в истории ценна, ключи на них
-не заводятся. Дефолтные итоговые значения = сегодняшним байт-в-байт: `claude-bot@mva154.local`,
-`deploy-finalizer@mva154.local`, `post-deploy-monitor@mva154.local` (BR-5).
-
-**A1 (`plane_sync.notify_stage_change`) — новых ключей НЕ требует:** база ссылок —
-`settings.gitea_public_url or settings.gitea_url` (точно та же fallback-семантика, что у
-существующих потребителей `notifications.py:901` и `usage.py:457,662`), owner —
-`settings.gitea_owner` (заменяет литерал `admin` в путях Branch/PR).
-
-Каждый новый ключ получает описательный комментарий в `config.py` (по образцу соседних блоков),
-строку в `.env.example` и в карте env `INFRA.md`. Контракт FR-2 после изменения: **ни один из
-акторов не содержит литералов `/home/slin` / `mva154` в исполняемом коде** (TC-03…TC-05).
-
-### D3 — Вопрос А-2: `SELF_HOSTING_REPO = "orchestrator"` остаётся платформенной константой
-
-**Решение: НЕ конфигурируем.** Имя self-hosting репо — **нормативная конвенция тиража**: «репо
-платформы в любом тираже обязан называться `orchestrator`» (фиксируется в REPLICATION.md §границы
-+ чек-лист). Обоснование:
-
-1. **Это узел безопасности, а не хост-значение.** На `is_self_hosting_repo` завязана семантика
-   «empty CSV → self-hosting only» **всех** `*_repos`-leaf'ов (merge-gate, image-freshness,
-   security, coverage, serial-gate freeze, fs-normalize, auto-labels, bug-fast-track, deploy-guard…).
-   Опечатка в гипотетическом `ORCH_SELF_HOSTING_REPO` либо **активирует деплой-машинерию на чужом
-   репо** (групповой риск), либо **молча выключает все self-гейты** на своём (класс «гейт тихо
-   исчез» — худший отказ по урокам ORCH-058). Константа делает оба отказа структурно невозможными.
-2. **Цена конвенции — ноль.** Тираж stateless (решение Славы 10.06): репо платформы создаётся
-   заново на целевой инфре (Type A — по инструкции Lite, Type B — в комплекте) — его имя полностью
-   под контролем оператора. Конфигурируемость не покупает ни одного сценария, который конвенция не
-   даёт бесплатно.
-3. Расширяемость не теряется: если будущий тираж потребует иного имени — отдельная задача с
-   guard'ами; этот ADR — зафиксированное место, откуда она стартует.
-
-Привязка: AC-1 (вариант «обоснованы в ADR задачи как платформенные константы»). Анти-дрейф: тест
-фиксирует константу (см. D10/TC-11-паттерн).
-
-### D4 — Вопрос А-1: staging-порт конфигурируем С fail-closed guard (инвариант ORCH-058 усилен)
-
-**Решение: конфигурируем порт, НЕ конфигурируем имена.** Новый ключ:
-
-- `staging_port: int = 8501` (env **`ORCH_STAGING_PORT`**) — заменяет модульную константу
-  `image_freshness._STAGING_PORT`; то же env-имя интерполируется в `command:` staging-сервиса
-  compose (`${ORCH_STAGING_PORT:-8501}`, реестр B6) → обе точки читают один факт (D1).
-- `_STAGING_SERVICE` / `_STAGING_COMPOSE_PROFILE` (`orchestrator-staging` / `staging`) —
-  **остаются константами**: имена сервисов/профиля нашего же compose-файла — платформенная
-  конвенция (логика D3); их разъезд с compose ломал бы rebuild внутри одного репо без выгоды.
-
-**Guard (ядро решения, NFR-4 / Р-2):** в начале freshness-пути (`check_staging_image_fresh`,
-ДО любого ssh/build/recreate) — проверка
-`settings.staging_port == settings.deploy_prod_target_port` → **отказ fail-closed**:
-`(False, "misconfiguration: ORCH_STAGING_PORT == prod target port (ORCH-058 AC-9) — staging rebuild refused")`
-+ best-effort Telegram-алерт. **Без тихого fallback на 8501** — молчаливая подмена порта хуже
-громкого отказа (оператор обязан починить env). Дисциплина explicit-pass ORCH-058 сохраняется:
-`TARGET_PORT=` по-прежнему передаётся хуку явно (`image_freshness.py:272`), источник теперь — один
-валидируемый конфиг-ключ вместо литерала. Инвариант «freshness-путь никогда не целится в прод»
-из подразумеваемого константой становится **исполняемым** (guard) — усиление, не ослабление.
-
-Примечание: при изменённом `ORCH_STAGING_PORT` ручной запуск хука `--build-staging` без env-прefix
-использует staging-дефолты хука (8501) — это документируется в REPLICATION.md (ручные запуски —
-с явным `TARGET_PORT=`); wired-путь (через `image_freshness`) всегда передаёт порт явно.
-
-Привязка: FR-1 A5, AC-8, TC-11.
-
-### D5 — Вопрос А-3: CMD Dockerfile остаётся `8500`; параметризация порта — на слое compose
-
-**Решение: `CMD` не трогаем** (exec-form, `--port 8500` — документированный дефолт образа):
-
-- `ARG` не подставляется в рантайм-CMD; shell-form CMD (`sh -c "… ${PORT}"`) менял бы
-  PID-1/сигнальную семантику — пара «`init: true` + exec-form» выверена (B-2, зомби-репарентинг
-  поддерева claude/node) и трогать её ради порта — риск без выгоды.
-- Порт конфигурируется там, где уже доказанно работает (staging так живёт с ORCH-31): **оба**
-  compose-сервиса получают явный `command:`: прод —
-  `["uvicorn","src.main:app","--host","0.0.0.0","--port","${ORCH_DEPLOY_PROD_TARGET_PORT:-8500}"]`,
-  staging — то же с `${ORCH_STAGING_PORT:-8501}`. **Реюз существующего env-имени**
-  `ORCH_DEPLOY_PROD_TARGET_PORT` (ключ `deploy_prod_target_port: 8500` уже описывает прод-порт для
-  деплой-пути) — вторая «истина» о прод-порте не вводится. Дефолтный резолв = байт-в-байт текущему
-  CMD → эффективная конфигурация 1:1 (AC-2; TC-06 сверяет резолв по значениям).
-
-**C1 (`useradd`):** `ARG APP_UID=1000 / APP_GID=1000 / APP_USER=slin / APP_HOME=/home/slin` в
-`Dockerfile`; compose `build.args` обоих сервисов прокидывают их из тех же env, что и рантайм:
-`APP_UID: ${ORCH_RUN_UID:-1000}`, `APP_GID: ${ORCH_RUN_GID:-1000}`,
-`APP_HOME: ${ORCH_AGENT_HOME_DIR:-/home/slin}` → uid/gid/HOME двигаются **одной согласованной
-группой** (инвариант ORCH-040, FR-3). `APP_USER` — косметика passwd-записи (важен факт записи для
-`getpwuid`/ssh, ORCH-058 Dockerfile:38, не имя), дефолт `slin`.
-
-Привязка: FR-1 C1–C2, §3.4 А-3, AC-6, TC-07.
-
-### D6 — Карта compose-интерполяции (реестр B) и согласованная группа ORCH-040
-
-Полная карта переменных `docker-compose.yml` (дефолты = текущим значениям; все три сервиса):
-
-| Переменная | Дефолт | Закрывает |
-|---|---|---|
-| `ORCH_HOST_REPOS_DIR` *(реюз)* | `/home/slin/repos` | B1 volumes ×3 (`:/repos`, у watchdog `:ro`) + environment ×2 (`ORCH_HOST_REPOS_DIR=` прокидывается тем же значением) |
-| `ORCH_HOST_CLAUDE_DIR` | `/home/slin/.claude` | B1 (source маунта) |
-| `ORCH_HOST_CLAUDE_JSON` | `/home/slin/.claude.json` | B1 (source, `:ro`) |
-| `ORCH_HOST_SSH_DIR` | `/home/slin/.orchestrator-ssh` | B1 (source, `:ro`) |
-| `ORCH_AGENT_HOME_DIR` *(= Settings-ключ D2)* | `/home/slin` | **таргеты** маунтов `.claude`/`.claude.json`/`.ssh` (`…:${ORCH_AGENT_HOME_DIR:-/home/slin}/.claude` и т.д.) + `build.args APP_HOME` |
-| `ORCH_HOST_CLAUDE_CODE_DIR` | `/usr/lib/node_modules/@anthropic-ai/claude-code` | B2 (`:/opt/claude-code:ro`) |
-| `ORCH_HOST_NODE_BIN` | `/usr/bin/node` | B2 (`:/usr/bin/node:ro`) |
-| `ORCH_DOCKER_GID` | `999` | B3 `group_add` ×3 — **«МИНА 1» НЕ удаляется**, меняется только литерал на `${ORCH_DOCKER_GID:-999}` |
-| `ORCH_RUN_UID` / `ORCH_RUN_GID` | `1000` / `1000` | B4 `user:` ×2 + `build.args APP_UID/APP_GID` |
-| `ORCH_DEPLOY_SSH_USER` *(реюз)* | `slin` | B5: `ORCH_DEPLOY_SSH_USER=`, `DEPLOY_SSH_USER=` (legacy enduro — то же значение через `${ORCH_DEPLOY_SSH_USER:-slin}`) |
-| `ORCH_DEPLOY_HOST_REPO_PATH` *(реюз)* | `/home/slin/repos/orchestrator` | B5 environment |
-| `DEPLOY_HOOK_SCRIPT` *(legacy)* | `/home/slin/bin/enduro-deploy-hook.sh` | B5 ×2 (`${DEPLOY_HOOK_SCRIPT:-…}`) |
-| `ORCH_STAGING_PORT` *(= Settings-ключ D4)* | `8501` | B6 `command:` staging |
-| `ORCH_DEPLOY_PROD_TARGET_PORT` *(реюз)* | `8500` | `command:` prod (D5) |
-
-Не параметризуются (зафиксировано): контейнерные пути (`/app/data`, `/repos`, `/opt/claude-code`,
-`/var/run/docker.sock`) — конвенция layout'а контейнера, не хост-специфика;
-`DEPLOY_SSH_HOST/ORCH_DEPLOY_SSH_HOST=127.0.0.1` — loopback при `network_mode: host`, валиден на
-любом single-host; имена сервисов/контейнеров/образов — платформенные константы (D3/D4; для образов
-истина уже в конфиге: `deploy_prod_source_image`/`deploy_prod_target_image`); `network_mode: host`,
-`init: true`, профиль `staging` — архитектурные решения, не значения.
-
-Группа ORCH-040 после изменения: `ORCH_RUN_UID/GID` + `ORCH_AGENT_HOME_DIR` + source-переменные
-маунтов меняются согласованно; при дефолтах резолв эквивалентен текущему файлу (TC-06).
-
-### D7 — Deploy-hook: env-override `REPO` + явная передача от инвокеров
-
-1. `scripts/orchestrator-deploy-hook.sh:38`: `REPO=/home/slin/repos/orchestrator` →
-   `REPO="${REPO:-/home/slin/repos/orchestrator}"` (паттерн остальных переменных хука; D1 реестра).
-2. **Оба инвокера передают `REPO` явно** (иначе на новом хосте env-override мёртв — сейчас хук
-   безусловно перезаписывает значение): `self_deploy.build_deploy_command` (prod env-прefix) и
-   `image_freshness` (`env_assignments`, строки ~268–275) добавляют
-   `REPO={shlex.quote(settings.deploy_host_repo_path)}` — тот же источник, которым инвокеры уже
-   делают `cd` (`image_freshness.py:277`). Конфиг становится единственной истиной на wired-пути;
-   дефолт хука сохраняет ручные операторские запуски на текущем хосте.
-
-**Инварианты не тронуты:** exit-code контракт хука (0/1/2, ORCH-036), шаги `--deploy`/`--rollback`/
-`--build-staging`, provenance-guard `EXPECTED_REVISION` (ORCH-058 Strategy B) — добавляется ровно
-одно env-присваивание в префикс команды. Привязка: FR-1 D1, AC-6, TC-08.
-
-### D8 — Вопрос А-4 (секреты): отдельный stdlib-скрипт `scripts/gen_secrets.py`
-
-**Форма: новый самостоятельный скрипт** (НЕ режим `onboard_project.py`: онбординг подключает проект
-к **живой** платформе, генерация секретов — provisioning **нового хоста**; это разные жизненные
-циклы и разные операторы, смешение связало бы независимые сценарии и раздуло CLI ORCH-009).
-
-Контракт (BR-3 / FR-4 / NFR-3 / AC-5, TC-09):
-
-- **stdlib-only** (`secrets`, `argparse`); генерирует `ORCH_PLANE_WEBHOOK_SECRET`,
-  `ORCH_GITEA_WEBHOOK_SECRET` через `secrets.token_hex(32)` (32 байта энтропии, 64 hex-символа;
-  повторный запуск — другие значения).
-- **Режим по умолчанию — печать в stdout** (`.env`-фрагмент: сгенерированные webhook-секреты +
-  плейсхолдеры внешних токенов + указатель на чек-лист); файлы не трогаются.
-- `--write [PATH=.env]`: **существующий файл → отказ с exit≠0 и внятным сообщением**; перезапись —
-  только явный `--force` (AC-5 «отказ/явное подтверждение»). Никогда не перезаписывает молча.
-- Состав ключей вывода согласован с `.env.example` (TC-09 сверяет программно).
-- **Инвентаризация секретов** (фиксация аудита FR-4.1): генерируемые локально —
-  `ORCH_PLANE_WEBHOOK_SECRET`, `ORCH_GITEA_WEBHOOK_SECRET`; выпускаемые внешними системами (только
-  чек-лист REPLICATION.md: где выпустить → куда вписать → как проверить) — `ORCH_PLANE_API_TOKEN`,
-  `ORCH_PLANE_BOT_*` (7, опциональны — fallback на API-токен), `ORCH_GITEA_TOKEN`,
-  `ORCH_TELEGRAM_BOT_TOKEN` (+несекретный `ORCH_TELEGRAM_CHAT_ID`), sidecar
-  `WATCHDOG_TG_BOT_TOKEN`/`WATCHDOG_TG_CHAT_ID` (ORCH-100, независимый канал). Нормативная строка:
-  **«боевые секреты текущего хоста не копируются ни на одном шаге»**.
-- `.env.example` дополняется до 100% обязательных ключей старта (включая новые D2/D4/D6);
-  секретные значения — только плейсхолдеры; `.env.staging.example` согласуется.
-
-### D9 — Вопрос А-4 (smoke): чистый runbook без нового скрипта
-
-**Форма: документированная процедура** `docs/operations/REPLICATION.md` (имя из ТЗ принято),
-собранная из **существующих кирпичей** — нового smoke-скрипта **не вводим**: каждый шаг уже имеет
-машинную команду с однозначным исходом; обвязка добавила бы поверхность сопровождения и LLM/сетевые
-зависимости без новой гарантии (AC-3 допускает «и/или скрипт»; TC-10 — «если введён»).
-
-Скелет процедуры (developer материализует; каждый шаг — явные PASS/FAIL):
-
-| Шаг | Команда/кирпич | PASS |
-|---|---|---|
-| 0. Конфиг резолвится | `docker compose config` | резолв без ошибок/未-переменных |
-| 1. Инстанс жив | `curl -fsS http://127.0.0.1:<port>/health` | HTTP 200 |
-| 2. Контракты отвечают | `GET /queue`, `GET /metrics` | JSON, штатные блоки, `schema_version: 1` |
-| 3. Тестовый проект | `scripts/onboard_project.py plan` → `apply` → `verify` (sandbox) | `verify` зелёный |
-| 4. Тестовая задача | создать issue в Plane → статус «To Analyse» | задача в БД, analyst-job в `GET /queue` |
-| 5. **Минимальный сигнал «конвейер доехал»** | дождаться окончания `analysis` | артефакты `01–04` в ветке задачи (`git ls-tree origin/<branch> docs/work-items/<id>/`) |
-| 6. Расширенный режим (опционально) | Approved → … → Confirm Deploy | задача дошла до `done` |
-
-Итог — однозначный вердикт PASS/FAIL; при FAIL — что собрать (логи контейнера, снапшот `/queue`).
-Stateless: ни один шаг не предполагает перенос данных/БД/секретов с боевого хоста.
-**Приёмка воспроизводимости (AC-3):** один прогон на текущей инфре — staging-песочница 8501 +
-sandbox-проект (исполняет tester, фиксация в `13-test-report.md`/`15-staging-log.md`).
-Границы «10-common vs Lite vs Bundled» — отдельный раздел REPLICATION.md (анти-скоуп-крип Р-5).
-
-### D10 — Анти-регресс сканер: механика исключений (NFR-5)
-
-`tests/test_no_host_hardcodes.py` (образец — `tests/test_agent_prompts_canon.py`):
-
-- **Список запрещённых литералов централизован в тесте:**
-  `FORBIDDEN = ("82.22.50.71", "/home/slin", "mva154", "duckdns")` — единственная точка правки.
-- **Зона скана:** `src/**/*.py` + `watchdog/**/*.py`. Вне зоны: `tests/**`, `docs/**`, `scripts/**`
-  (deploy-hook несёт легитимный shell-default D7), `.env*`.
-- **Структурное исключение — `src/config.py` и `watchdog/config.py` целиком:** это канонические
-  места дефолтов (BR-1), и их дефолты **обязаны** нести боевые значения (BR-5: `/home/slin`,
-  `mva154.local`) — сканировать их значило бы держать вечно непустой allowlist. Исключение —
-  правило теста с комментарием-обоснованием, не allowlist-запись.
-- **Исключение комментариев/докстрингов** — через `tokenize` (надёжнее построчных regex: судит
-  токены `COMMENT`/`STRING`-докстринги, а не текст; детерминирован — NFR-5).
-- **Allowlist-механизм** (`{(file, literal): "обоснование"}`) существует и **пуст на сдаче**
-  (после D2/D7 код-блокеров не остаётся; `fs_normalize.healing_command` except-ветка
-  (`/repos/_wt`, `1000:1000`) запрещённых литералов **не содержит** и остаётся как never-raise
-  floor — главный путь уже строит подсказку из settings, отдельной правки A7 не требуется).
-- **Негативная самопроверка (TC-02):** сканер прогоняется по синтетическому фрагменту с
-  подсаженным литералом и обязан его поймать (тест не вечно-зелёный).
-
-### Что НЕ меняется (граница решения)
-
-- `STAGE_TRANSITIONS`, состав `QG_CHECKS`, семантика `check_*`, machine-verdict ключи, схема БД —
-  байт-в-байт (NFR-6); новые тесты входят в существующие гейты (`check_ci_green`/merge-gate re-test)
-  автоматически.
-- Значения существующих дефолтов реестра E (`02-trz.md` §3.1) — не меняются (BR-5).
-- A8 (`disk_watchdog` fallback `["/repos","/app/data"]`) — config-backed зеркало, остаётся как есть
-  (синхронность с конфиг-дефолтом фиксирует существующий тест-ландшафт; вводить «одну точку истины»
-  ради неблокера — лишний диф).
-- A9 (`projects._DEFAULT_PROJECTS`) — документированный fallback, не трогаем; чек-лист REPLICATION.md
-  обязывает `ORCH_PROJECTS_JSON` на новом хосте.
-- A10 (`watchdog/config.py` `metrics_url` 127.0.0.1:8500) — уже env-driven; при смене прод-порта
-  оператор задаёт `WATCHDOG_METRICS_URL` (строка чек-листа о когерентности портов:
-  `ORCH_DEPLOY_PROD_TARGET_PORT` ⇄ `WATCHDOG_METRICS_URL` ⇄ `ORCH_POST_DEPLOY_BASE_URL`).
-- `onboarding/` (ORCH-009) — не форкается; новые env-ключи отражаются в его `.env.example`-скелете
-  только при фактическом расхождении.
-
-## Альтернативы
-
-- **`ORCH_SELF_HOSTING_REPO` как конфиг-ключ** — отвергнуто: превращает опечатку оператора в
-  активацию деплой-машинерии на чужом репо или тихое выключение всех self-гейтов (D3); конвенция
-  бесплатна при stateless-тираже.
-- **`_STAGING_PORT` оставить константой** — отвергнуто: реестр B6 (AC-6) требует параметризации
-  порта в compose `command:`; константа в `image_freshness` при конфигурируемом compose-порте даёт
-  рассинхрон (rebuild целится в 8501, staging слушает иное) — хуже управляемой пары
-  «ключ + fail-closed guard» (D4).
-- **Тихий fallback guard'а на 8501 при misconfig** — отвергнуто: молчаливая подмена таргета —
-  ровно тот класс отказа, против которого ORCH-058 строился; отказ громче и честнее.
-- **Shell-form CMD / `ENV PORT` в Dockerfile** — отвергнуто: меняет PID-1/сигнальную семантику
-  выверенной пары `init: true` + exec-form (B-2) ради порта, который уже параметризуем на слое
-  compose (D5).
-- **Генератор секретов как режим `onboard_project.py`** — отвергнуто: разные жизненные циклы
-  (онбординг проекта на живой платформе vs provisioning хоста), связывание независимых
-  операторских сценариев (D8).
-- **Отдельный smoke-скрипт-обвязка** — отвергнуто (сейчас): каждый шаг runbook уже машинно
-  проверяем существующими кирпичами; скрипт = новая поверхность сопровождения без новой гарантии.
-  Дверь открыта: Lite/Bundled-задачи могут ввести обвязку поверх того же runbook (D9).
-- **Allowlist-записи для `config.py` вместо структурного исключения** — отвергнуто: allowlist
-  обязан быть пуст (AC-1/AC-7); вечные записи о легитимных дефолтах девальвируют его сигнал (D10).
-
-## Последствия
-
-- **+** Платформа разворачивается на новой инфре только env/конфигом: четыре код-блокера закрыты
-  тремя ключами + реюзом существующих; инфра-файлы интерполируются; секреты выпускаются заново;
-  smoke даёт явный PASS/FAIL. Критический путь эпика ORCH-10 разблокирован.
-- **+** Инвариант ORCH-058 усилен: анти-prod-гарантия freshness-пути теперь исполняемый guard,
-  а не подразумеваемая константа.
-- **+** Возврат хардкода ломает CI структурно (сканер), а не ловится ревью.
-- **−** Поверхность конфигурации растёт (~13 новых env-имён). Митигейшн: дефолты = боевым
-  значениям (ничего настраивать на текущем хосте не нужно), карта env в INFRA.md/REPLICATION.md,
-  TC-06/TC-08 сверяют полноту и резолв.
-- **−** Правка двух safety-critical билдеров команд (D7) и compose-файла прод-сервиса (D5).
-  Митигейшн: изменения чисто аддитивные (одно env-присваивание; `command:` = текущему CMD),
-  exit-контракт хука не тронут, полный регресс + staging-гейт 8501 перед прод-деплоем (NFR-1).
-- **−** Compose-интерполяция читает `.env`/shell, а не `env_file` — возможна операторская путаница
-  на staging. Митигейшн: правило явно зафиксировано (D1) и попадает в REPLICATION.md.
-- **Откат:** не задавать новые переменные (дефолты = прежнее поведение — kill-switch-природа,
-  NFR-2); полный откат — revert PR (изменение конфигурационное, без миграций состояния).
-
-## Ссылки
-
-- BRD: `docs/work-items/ORCH-101/01-brd.md`
-- TRZ: `docs/work-items/ORCH-101/02-trz.md` (нормативный реестр §3.1, вопросы §3.4 А-1…А-5)
-- Acceptance: `docs/work-items/ORCH-101/03-acceptance-criteria.md` (AC-1…AC-8)
-- Test plan: `docs/work-items/ORCH-101/04-test-plan.yaml` (TC-01…TC-12)
-- Сквозной ADR: `docs/architecture/adr/adr-0036-replication-foundation-host-parametrization.md`
-- Инварианты соседей: `docs/architecture/adr/adr-0005-container-runs-as-host-uid.md` (ORCH-040),
-  `adr-0008-staging-image-provenance.md` (ORCH-058), `adr-0007-executable-self-deploy.md` (ORCH-036),
-  `adr-0035-turnkey-project-onboarding.md` (ORCH-009)
-- Сверено по коду: `src/plane_sync.py:1064`, `src/agents/launcher.py:592–599,823–831`,
-  `src/self_deploy.py:330–337`, `src/post_deploy.py:573–580`, `src/image_freshness.py:60–62,263–280`,
-  `src/qg/checks.py:517`, `src/fs_normalize.py:529–540`, `src/config.py:33–49,193–209`,
-  `docker-compose.yml`, `Dockerfile`, `scripts/orchestrator-deploy-hook.sh:38`

docs/work-items/ORCH-101/07-infra-requirements.md

@@ -1,80 +0,0 @@
----
-work_item: ORCH-101
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 07 — Инфра-требования: ORCH-101 — ORCH-10-common: расхардкод + секреты + smoke
-
-Work Item: **ORCH-101** · Repo: **orchestrator** · Стадия: architecture
-
-> Топология НЕ меняется (контейнеры/порты/сеть/тома — те же при дефолтах); меняется
-> **параметризуемость** инфра-файлов. Раздел фиксирует карту переменных и правила раската.
-
-## I-1. Топология / окружения
-
-- **Без изменений при дефолтах:** те же 3 сервиса (`orchestrator` 8500, `orchestrator-watchdog`,
-  `orchestrator-staging` 8501 под профилем `staging`), `network_mode: host`, те же тома и
-  `group_add` docker-gid («МИНА 1» ORCH-040 — сохраняется, литерал → `${ORCH_DOCKER_GID:-999}`).
-- `docker-compose.yml` переводится на интерполяцию `${VAR:-default}` (реестр ТЗ §3.1 B; карта —
-  ADR-001 D6); `Dockerfile` получает `ARG APP_UID/APP_GID/APP_USER/APP_HOME` (D5); оба сервиса
-  получают явный `command:` с портом из env (`${ORCH_DEPLOY_PROD_TARGET_PORT:-8500}` /
-  `${ORCH_STAGING_PORT:-8501}`) — дефолтный резолв эквивалентен текущей конфигурации (AC-2/TC-06).
-- **Источник интерполяции** — `.env` проекта / shell-окружение (НЕ `env_file` сервиса):
-  интерполяционные значения тиража живут в `.env` (ADR-001 D1; попадает в REPLICATION.md).
-- Имена сервисов/контейнеров/образов, профиль `staging`, `network_mode: host`, контейнерные пути
-  (`/app/data`, `/repos`, `/opt/claude-code`) — платформенные константы (ADR-001 D3/D4/D6).
-
-## I-2. Переменные окружения / секреты
-
-**Новые `Settings`-ключи** (дефолт = боевому значению; см. ADR-001 D2/D4):
-
-| env | Дефолт | Назначение |
-|---|---|---|
-| `ORCH_AGENT_HOME_DIR` | `/home/slin` | HOME акторских процессов (launcher ×2 / self-deploy / post-deploy) + таргеты маунтов + `APP_HOME` |
-| `ORCH_AGENT_GIT_NAME` | `claude-bot` | git-имя агентских коммитов |
-| `ORCH_GIT_EMAIL_DOMAIN` | `mva154.local` | домен git-email всех акторов (`<actor>@<domain>`) |
-| `ORCH_STAGING_PORT` | `8501` | порт staging: `image_freshness` (c guard'ом ≠ прод-порт) + compose `command:` |
-
-**Новые compose-only переменные:** `ORCH_HOST_CLAUDE_DIR`, `ORCH_HOST_CLAUDE_JSON`,
-`ORCH_HOST_SSH_DIR`, `ORCH_HOST_CLAUDE_CODE_DIR`, `ORCH_HOST_NODE_BIN`, `ORCH_DOCKER_GID`,
-`ORCH_RUN_UID`, `ORCH_RUN_GID` (дефолты — текущие значения; полная карта — ADR-001 D6).
-**Реюз существующих имён:** `ORCH_HOST_REPOS_DIR`, `ORCH_DEPLOY_SSH_USER`,
-`ORCH_DEPLOY_HOST_REPO_PATH`, `ORCH_DEPLOY_PROD_TARGET_PORT`, legacy `DEPLOY_HOOK_SCRIPT`.
-**Deploy-hook:** `REPO="${REPO:-/home/slin/repos/orchestrator}"` + явная передача `REPO=` обоими
-инвокерами (ADR-001 D7).
-
-**Секреты (BR-3 / AC-5):** новый stdlib-скрипт `scripts/gen_secrets.py` — криптослучайные
-`ORCH_PLANE_WEBHOOK_SECRET`/`ORCH_GITEA_WEBHOOK_SECRET` (`secrets.token_hex(32)`), печать по
-умолчанию, `--write` с отказом при существующем `.env` (перезапись только `--force`). Внешние
-токены (`ORCH_PLANE_API_TOKEN`, `ORCH_PLANE_BOT_*`, `ORCH_GITEA_TOKEN`, `ORCH_TELEGRAM_BOT_TOKEN`,
-`WATCHDOG_TG_*`) — по чек-листу REPLICATION.md (где выпустить → куда вписать → как проверить).
-Боевые секреты текущего хоста не покидают его (NFR-3); в гит — только шаблоны/плейсхолдеры
-(правило агентов №8); `.env.example` доводится до 100% обязательных ключей, `.env.staging.example`
-согласуется.
-
-**Карта env в `docs/operations/INFRA.md`** дополняется всеми новыми ключами; deployment-раздел —
-новый `docs/operations/REPLICATION.md` (FR-7). Чек-лист тиража обязывает: `ORCH_PROJECTS_JSON`
-(fallback-реестр UUID'ов чужого Plane не сматчится), когерентность портов
-`ORCH_DEPLOY_PROD_TARGET_PORT` ⇄ `WATCHDOG_METRICS_URL` ⇄ `ORCH_POST_DEPLOY_BASE_URL`.
-
-## I-3. Деплой / рестарт
-
-- **Рестарт прод-контейнера в рамках задачи — НЕ требуется и запрещён** (NFR-1, self-hosting):
-  правки `docker-compose.yml`/`Dockerfile`/хука инертны до следующего штатного деплоя через
-  конвейер (staging 8501 → ручной `Confirm Deploy`, ORCH-059).
-- На текущем хосте ничего донастраивать не нужно: все дефолты = боевым значениям; пустой/
-  неизменённый `.env` → поведение 1:1 (BR-5). Откат = не задавать переменные (NFR-2).
-- Инвариант ORCH-058 сохранён и усилен: freshness-путь fail-closed отказывает при
-  `ORCH_STAGING_PORT == прод-порт` (ADR-001 D4); INV-4 не затрагивается.
-
-## I-4. CI/CD
-
-- `.gitea/workflows/` — **без изменений**. Новые тесты (`test_no_host_hardcodes.py`,
-  `test_host_config_keys.py`, `test_infra_parametrization.py`, `test_secrets_gen.py`,
-  `test_replication_smoke.py`) попадают в существующие гейты (`check_ci_green`/
-  `check_tests_passed`/merge-gate re-test) автоматически — новых QG не вводится (NFR-6).
-- Новых pip/системных зависимостей нет (генератор секретов — stdlib).

docs/work-items/ORCH-101/08-data-requirements.md

@@ -1,32 +0,0 @@
----
-work_item: ORCH-101
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 08 — Требования к данным: ORCH-101 — ORCH-10-common: расхардкод + секреты + smoke
-
-Work Item: **ORCH-101** · Repo: **orchestrator** · Стадия: architecture
-
-> When-applicable / информационный. Задача конфигурационная — данные и схема БД не затрагиваются;
-> файл создан для аудитопригодности с явными `N/A`.
-
-## Изменения схемы БД
-
-`N/A` — таблицы/индексы/миграции не добавляются и не меняются; `init_db()` не трогается (NFR-6,
-ТЗ §5). Тираж stateless (решение Славы 10.06): перенос данных/БД с боевого хоста не предполагается
-ни одним шагом (smoke-процедура это явно проверяет — AC-3).
-
-## Новые/изменённые сущности
-
-Нет. Новые конфиг-ключи (`agent_home_dir`, `agent_git_name`, `git_email_domain`, `staging_port`) —
-слой `Settings` (env), не данные.
-
-## Совместимость данных / миграции
-
-`N/A` — общая прод-БД (self-hosting, enduro-trails) не затрагивается; `ORCH_DB_PATH` и layout
-`/app/data` остаются прежними (контейнерные пути — платформенная конвенция, ADR-001 D6). На новом
-хосте БД создаётся с нуля штатным `init_db()`.

docs/work-items/ORCH-101/10-tech-risks.md

@@ -1,38 +0,0 @@
----
-work_item: ORCH-101
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 10 — Технические риски: ORCH-101 — ORCH-10-common: расхардкод + секреты + smoke
-
-Work Item: **ORCH-101** · Repo: **orchestrator** · Стадия: architecture
-
-> Информационный (гейтом не парсится). Детализация рисков Р-1…Р-5 BRD §8 в привязке к решениям
-> ADR-001 (D1…D10).
-
-## Реестр рисков
-
-| ID | Риск | Вер. | Влия. | Митигейшн |
-|----|------|------|-------|-----------|
-| TR-1 | **Регресс горячих путей при параметризации env-словарей акторов** (launcher ×2 / self-deploy / post-deploy): опечатка в ключе/дефолте ломает git-коммиты или credentials-резолв claude CLI (HOME) у ВСЕХ проектов общего инстанса (Р-1 BRD) | Низ. | Выс. | Дефолты байт-в-байт = боевым (`/home/slin`, `claude-bot@mva154.local` — BR-5); TC-04/TC-05 фиксируют итоговые словари при дефолтах И при переопределении; полный регресс TC-12; staging-гейт 8501 перед прод-выкатом (NFR-1) |
-| TR-2 | **Ослабление инварианта ORCH-058 при конфигуризации staging-порта** (`ORCH_STAGING_PORT=8500` нацеливает rebuild/recreate на прод; Р-2 BRD) | Низ. | Выс. | Fail-closed guard ДО любого ssh/build: `staging_port == deploy_prod_target_port` → отказ + алерт, без тихого fallback (ADR-001 D4); explicit-pass `TARGET_PORT=` хуку сохранён; TC-11 проверяет guard |
-| TR-3 | **Флап анти-регресс сканера** (ложные срабатывания на комментарии/докстринги или вечно-непустой allowlist из-за дефолтов config.py; Р-3 BRD) | Сред. | Низ. | `tokenize`-исключение комментариев/докстрингов (не regex); структурное исключение `src/config.py`+`watchdog/config.py` как канонических мест дефолтов (BR-1); негативная самопроверка TC-02; список литералов централизован (ADR-001 D10) |
-| TR-4 | **Неполный аудит**: пропущенный хардкод всплывает на первом реальном тираже (Р-4 BRD) | Сред. | Сред. | Реестр §3.1 нормативен и перепроверен на стадии architecture повторным grep'ом (код-блокеры = ровно A1–A4, см. ADR-001 «Контекст»); сканер CI держит классы литералов навсегда; smoke-процедура (D9) — последняя линия обнаружения на целевой инфре |
-| TR-5 | **Правка safety-critical билдеров команд деплоя** (D7: `build_deploy_command` / `image_freshness` env-prefix; D5: `command:` прод-сервиса compose) — ошибка ломает self-deploy/rollback | Низ. | Выс. | Изменения строго аддитивные: одно env-присваивание `REPO=` (exit-контракт хука 0/1/2 не тронут, ORCH-036 прочитан); `command:` прод = байт-в-байт текущему CMD при дефолтах (TC-06); существующие self-deploy/freshness тесты + staging-прогон |
-| TR-6 | **Путаница источников env**: compose-интерполяция читает `.env`/shell, а не `env_file` (`.env.staging` НЕ влияет на `${VAR}`) → оператор тиража задаёт переменную «не туда» | Сред. | Низ. | Правило явно зафиксировано (ADR-001 D1) и входит в REPLICATION.md; дефолты делают ошибку безопасной (резолв в боевые значения, не в мусор); TC-06 проверяет дефолт-резолв |
-| TR-7 | **Рассинхрон группы ORCH-040** (uid/gid/HOME/маунты/`useradd`) при частичном переопределении (например, сменили `ORCH_AGENT_HOME_DIR`, забыли пересобрать образ с `APP_HOME`) | Низ. | Сред. | Группа управляется одними env-именами насквозь (compose `build.args` ← те же `ORCH_RUN_UID/GID`/`ORCH_AGENT_HOME_DIR`, ADR-001 D5/D6); «МИНА 1» `group_add` сохранена; согласованная группа описана в REPLICATION.md как «менять вместе»; TC-06/TC-07 |
-| TR-8 | **Слабые/затёртые секреты**: детерминированная генерация или молчаливая перезапись `.env` уничтожает работающий комплект | Низ. | Выс. | `secrets.token_hex(32)` (криптослучайно, 32 байта); отказ при существующем файле, перезапись только явным `--force` (NFR-3, ADR-001 D8); TC-09 проверяет различие повторных запусков и отказ |
-
-## Сводный вывод
-
-Доминирующий класс — **регресс общего прод-инстанса через горячие пути** (TR-1/TR-2/TR-5):
-вероятность низкая (kill-switch-природа дефолтов: на текущем хосте без новых env поведение 1:1),
-влияние высокое (self-hosting, общая БД с enduro-trails) → ключевая страховка — полный регресс +
-обязательный staging-гейт 8501 + ручной `Confirm Deploy` (прод-контейнер в рамках задачи не
-рестартуется, NFR-1). Эскалация `arch:major-change` **не требуется**: ни новой стадии, ни нового
-компонента, ни смены БД — конвейер и QG байт-в-байт (NFR-6); возврат в анализ не нужен (ТЗ
-выполнимо без нарушения принципов). Остаточный риск для прод-конвейера — **низкий**.

docs/work-items/ORCH-101/12-review.md

@@ -1,118 +0,0 @@
----
-verdict: APPROVED
-work_item: ORCH-101
-stage: review
-author_agent: reviewer
-status: approved
-created_at: 2026-06-10
-model_used: claude-opus-4-8
-type: review
-work_item_id: ORCH-101
-version: 1
----
-
-# Review ORCH-101 — ORCH-10-common: расхардкод + секреты + smoke (фундамент тиража)
-
-## Summary
-
-PR (`feature/ORCH-101-orch-10-common-smoke`, commit `f1635dd`) реализует фундамент тиража
-ровно по ТЗ (`02-trz.md`) и ADR (`06-adr/ADR-001`, D1–D10): нормативный реестр хардкодов §3.1
-закрыт полностью, секреты нового хоста выпускаются `scripts/gen_secrets.py`, smoke-процедура —
-runbook `docs/operations/REPLICATION.md` с явными PASS/FAIL. Полный `pytest tests/ -q` зелёный
-(**1764 passed**), включая 6 новых/адаптированных тест-модулей. P0/P1 findings — нет;
-два косметических P3. Вердикт: **APPROVED**.
-
-### Ось 1 — Соответствие ТЗ (FR-1…FR-7, AC-1…AC-8)
-
-| AC | Статус | Проверено |
-|----|--------|-----------|
-| AC-1 ноль хардкодов в `src/**` | ✅ | A1 `plane_sync.notify_stage_change` → `gitea_public_url or gitea_url` + `gitea_owner` (семантика существующих потребителей, литералы `git.mva154.duckdns.org`/`/admin/` удалены); A2 — единый `launcher.agent_git_env()` для ОБОИХ мест (Popen агента + post-run git); A3/A4 — `self_deploy`/`post_deploy` читают `agent_home_dir`/`git_email_domain`, платформенные имена `deploy-finalizer`/`post-deploy-monitor` сохранены (D2); A5 → ключ `staging_port` + guard (D4); A6 → платформенная константа c обоснованием в ADR D3 и пин-тестом (`test_self_hosting_repo_is_platform_constant` фиксирует и значение, и ОТСУТСТВИЕ конфиг-ключа); A7 — основной путь уже config-backed, except-ветка запрещённых литералов не содержит (ADR D10). Контрольный grep: остаточные `mva154`/`/home/slin` в `src/**`/`watchdog/**` — только комментарии/докстринги. Сканер существует, allowlist пуст, зелёный |
-| AC-2 zero-regression | ✅ | дефолты новых ключей = боевым (`test_new_settings_defaults_equal_previous_production_values`, судит по `Settings.model_fields` — иммунно к ambient env); реестр E не тронут (там же); резолв compose при пустом env = боевым значениям (TC-06, `EXPECTED_DEFAULTS` — единая нормативная карта); `pytest tests/ -q` → 1764 passed; `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/verdict-ключи/схема БД дифф не трогает |
-| AC-3 smoke-процедура | ✅* | `REPLICATION.md` §4: 7 шагов, каждый с явными PASS/FAIL, однозначный итоговый вердикт; stateless (§5); кирпичи существующие (D9, скрипт-обвязка сознательно не вводилась). *Прогон воспроизводимости — стадия `testing` (см. «Передача тестеру») |
-| AC-4 доки + CHANGELOG | ✅ | см. раздел «Документация» ниже |
-| AC-5 секреты | ✅ | `secrets.token_hex(32)` = 64 hex (тест `test_secret_is_cryptorandom_64_hex` + неравенство повторных запусков); `--write` через `open(path, "x")` — атомарный отказ exit=2 на существующем файле, перезапись только `--force` (NFR-3, покрыто тестами); чек-лист внешних токенов §3.2 (где выпустить → куда вписать → как проверить) + норматив «боевые секреты не копируются»; `.env.example` дополнен (полнота сверяется `test_env_example_contains_*` и `test_output_keys_consistent_with_env_example`); реальных секретов в гите нет (плейсхолдеры пустые, анти-тест `test_no_real_secret_committed_anywhere_near`) |
-| AC-6 инфра-файлы | ✅ | реестр B1–B6/C1–C2/D1 закрыт: compose — полная интерполяция `${VAR:-default}` (карта D6 1:1); Dockerfile — `ARG APP_UID/GID/USER/HOME`, CMD exec-form 8500 сознательно сохранён (D5, PID-1/сигнальная семантика); hook — `REPO="${REPO:-…}"` + ОБА инвокера передают `REPO=` явно (D7, иначе override был бы мёртв — закрыто `test_rebuild_staging_passes_configured_port_and_repo`/`test_build_deploy_command_passes_repo_explicitly`) |
-| AC-7 анти-регресс | ✅ | `test_no_host_hardcodes.py`: централизованный `FORBIDDEN`, `tokenize`-исключение комментариев/докстрингов (NFR-5, детерминирован), структурное исключение config-модулей по ADR D10 (не allowlist-запись), allowlist пуст + тест на пустоту, негативные самопроверки ×4 (plain/env-dict/f-string/значение при докстринге выше) + guard от пустой зоны скана (`test_scan_zone_is_nonempty`) |
-| AC-8 self-hosting / инварианты | ✅ | прод-контейнер не трогается (изменения compose/Dockerfile вступают в силу на следующем штатном деплое); ORCH-058 **усилен**: fail-closed guard `staging_port == deploy_prod_target_port` → отказ ДО любого ssh/build, без тихого fallback, + Telegram-алерт (тесты: guard срабатывает на 8500/8500 и НЕ срабатывает на дефолте 8501/8500); INV-4 не затронут; маркеры соседей сохранены (ось 2) |
-
-### Ось 2 — Соответствие ADR + трассировка (TRACEABILITY)
-
-Реализация 1:1 по D1–D10. Правки блоков с чужими маркерами сверены с их ADR:
-
-- **ORCH-040** (adr-0005): `group_add` «МИНА 1» сохранён на всех трёх сервисах (только литерал →
-  `${ORCH_DOCKER_GID:-999}`); uid/gid/HOME/маунт-таргеты двигаются одной группой env
-  (`user:` + `build.args APP_*` + таргеты `.claude`/`.ssh` — все от `ORCH_RUN_UID/GID`/
-  `ORCH_AGENT_HOME_DIR`); адаптация `test_orch040_compose.py` корректна — судит резолв дефолтов,
-  инвариант НЕ ослаблен (смена дефолта по-прежнему валит тест).
-- **ORCH-058** (adr-0008): explicit-pass дисциплина сохранена (`TARGET_PORT=` по-прежнему передаётся
-  явно, источник — валидируемый ключ); анти-prod инвариант из подразумеваемой константы стал
-  исполняемым guard'ом — усиление, не ослабление; имена сервиса/профиля остались константами.
-- **ORCH-036** (adr-0007): exit-code контракт хука 0/1/2 не тронут — в префикс добавлено ровно одно
-  env-присваивание `REPO=`; detached Phase B не изменён.
-- **INV-4**: дифф не содержит push/force-push в `main`; merge-путь не тронут.
-- Сквозной `adr-0036` заведён (кросс-каттинг по TRACEABILITY — корректно, блоки несут 3 маркера).
-
-### Ось 3 — Качество кода
-
-- `agent_git_env()` устраняет дублирование ×2 в launcher (DRY) и структурно исключает дрейф двух
-  мест; docstrings на всех новых публичных функциях (`agent_git_env`, `generate_secret`,
-  `build_fragment`, `main`).
-- Guard в `check_staging_image_fresh` размещён правильно: после дешёвых kill-switch/`applies`
-  (нулевой оверхед для неприменимых репо), ДО любого ssh/build; Telegram-алерт best-effort
-  (`try/except`, never-raise сохранён).
-- Тесты содержательные: функциональные через monkeypatch-швы (link-build без сети, guard, передача
-  `REPO=`/`TARGET_PORT=` в собранную команду), структурные пины там, где env-словарь строится inline
-  в never-raise акторе — осознанный выбор, задокументирован в докстринге модуля. Негативные
-  самопроверки исключают «вечно-зелёный» сканер. `test_deploy_hook_rollback_sim.py` переведён на
-  env-override `REPO` — симуляция теперь дополнительно доказывает работоспособность override.
-- Security: секретные значения в `.env.example` — пустые плейсхолдеры; генератор не несёт зашитых
-  hex-значений (анти-тест); `open(..., "x")` — race-safe отказ от перезаписи.
-
-### Ось 4 — Документация
-
-Полностью обновлена в том же PR, см. раздел «Документация» ниже. README «Известные ограничения»
-(ORCH-079): ни один из трёх открытых пунктов (Telegram 48h / intra-repo deps / пакетный автоном)
-задачей не закрывается — обновление витрины не требуется; таблица env README дополнена.
-
-## Findings
-
-### P0 — Blocker
-— нет.
-
-### P1 — Must fix
-— нет.
-
-### P2 — Should fix
-— нет.
-
-### P3 — Nice to have (не блокирует, на усмотрение следующих задач)
-- [ ] `src/plane_sync.py::notify_stage_change`: при пустых ОБОИХ `gitea_public_url`/`gitea_url`
-  (нештатная конфигурация) собирается некорректная Markdown-ссылка вида `(/owner/...)`. Покрыто
-  never-raise конвертом и нереально при валидном конфиге (у `gitea_url` непустой дефолт);
-  опциональный guard «пустая база → пропустить ссылку» — косметика. Правило: ТЗ FR-1/A1 требует
-  только источник из Settings — выполнено.
-- [ ] `tests/test_no_host_hardcodes.py::find_violations`: эвристика statement-position пропускает
-  любой bare-string-statement (не только докстринги) — теоретический класс ложноотрицательных
-  (литерал в строке-выражении без присваивания). Реалистичные паттерны регрессии (env-dict,
-  f-string, RHS-значение) закрыты негативными самопроверками; ужесточение — отдельной задачей при
-  желании. Правило: NFR-5/AC-7 — выполнены как сформулированы.
-
-## Документация
-
-| Артефакт | Статус |
-|----------|--------|
-| `CHANGELOG.md` | ✅ запись ORCH-101 (детальная, по слоям D1–D10) |
-| `CLAUDE.md` | ✅ новая секция «Тираж платформы: фундамент 10-common» |
-| `README.md` | ✅ таблица env (+6 строк ORCH-101) + ссылка на REPLICATION.md; «Известные ограничения» не затронуты (корректно) |
-| `docs/architecture/README.md` | ✅ секция ORCH-101 со ссылками на adr-0036/work-item ADR |
-| `docs/operations/INFRA.md` | ✅ карта env дополнена (7 строк) + норматив секретов + когерентность портов |
-| `docs/operations/REPLICATION.md` | ✅ новый runbook: границы/конвенции, карта env, секреты, smoke PASS/FAIL, stateless |
-| ADR per work-item + сквозной | ✅ `06-adr/ADR-001-…` + `adr-0036-…` (frontmatter-схема 52c корректна) |
-| `.env.example` / `.env.staging.example` | ✅ полнота ключей старта (закреплена тестами) / согласован |
-
-## Передача тестеру (не findings)
-
-- **AC-3 (воспроизводимость):** заявленный прогон smoke-процедуры на текущей инфре
-  (staging 8501 + sandbox-проект) исполняется на стадии `testing` и фиксируется в
-  `13-test-report.md`/`15-staging-log.md` — без этой фиксации AC-3 не считается закрытым.
-- Smoke `serial_gate`/`GET /queue` — штатно по канону tester-промпта.

docs/work-items/ORCH-101/13-test-report.md

@@ -1,88 +0,0 @@
----
-result: PASS   # PASS | FAIL — машинный вердикт, UPPERCASE
-work_item: ORCH-101
-stage: testing
-author_agent: tester
-status: pass
-created_at: 2026-06-10
-model_used: claude-opus-4-8
-type: test-report
-work_item_id: ORCH-101
----
-
-# Test Report — ORCH-101 — ORCH-10-common: расхардкод + секреты + smoke (фундамент тиража)
-
-## Окружение
-- Python: 3.12.13
-- pytest: 8.3.3 (plugins: cov-5.0.0, anyio-4.13.0, asyncio-0.23.8)
-- Дата: 2026-06-10
-- Worktree: `/repos/_wt/orchestrator/feature_ORCH-101-orch-10-common-smoke`
-- Ветка: `feature/ORCH-101-orch-10-common-smoke` (HEAD `26fe4cd`, код задачи — `f1635dd`)
-- Прогон выполнен в worktree ветки задачи (не в общем `/repos/orchestrator`).
-- Вердикт ревью (`12-review.md`): **APPROVED**.
-
-## Smoke API (read-only)
-| Проверка | Результат |
-|----------|-----------|
-| `GET /health` | PASS — `{"status":"ok","service":"orchestrator"}` |
-| `GET /status` | PASS — активная задача ORCH-101 на стадии `testing` |
-| `GET /queue` | PASS — отдаёт полезную нагрузку |
-| Блок `serial_gate` в `/queue` (ORCH-088) | PASS — присутствует; `orchestrator.active_task = ORCH-101 (testing)`, не заморожен |
-| Блок `auto_labels` в `/queue` (ORCH-089) | PASS — присутствует (`enabled`, `autoApprove`/`autoDeploy`) |
-| `GET /metrics` | PASS — `schema_version:1`, стадия ORCH-101 видна |
-
-## Smoke-процедура тиража (AC-3 / FR-5)
-Воспроизводимость smoke-runbook подтверждена на текущей инфре (read-only, без переноса данных):
-| Шаг | Результат |
-|-----|-----------|
-| `docs/operations/REPLICATION.md` существует (runbook с PASS/FAIL) | PASS (13 КБ) |
-| `scripts/gen_secrets.py` запускается в безопасном (print) режиме | PASS — exit 0, файлы не тронуты |
-| Webhook-секреты крипто-случайны (64 hex = 32 байта) | PASS — `ORCH_PLANE_WEBHOOK_SECRET`/`ORCH_GITEA_WEBHOOK_SECRET` |
-| Внешние токены — только плейсхолдеры (пустые) | PASS |
-| Инстанс поднят и health-check зелёный (см. Smoke API) | PASS |
-
-## Результаты (покрытие TC из `04-test-plan.yaml`)
-
-| TC ID | Описание | Покрывающие тесты | Результат |
-|-------|----------|-------------------|-----------|
-| TC-01 | Анти-регресс скан: нет запрещённых литералов в исполняемом коде `src/**`+`watchdog/**` (AC-1, AC-7) | `test_no_host_hardcodes::test_no_host_hardcodes_in_executable_code`, `test_scan_zone_is_nonempty`, `test_allowlist_is_empty_at_acceptance` | PASS |
-| TC-02 | Негативная самопроверка сканера: подсаженный литерал детектируется (AC-7) | `test_scanner_catches_planted_literal_in_code`/`_in_env_dict`/`_in_fstring`, `test_scanner_ignores_comments_and_docstrings` | PASS |
-| TC-03 | `plane_sync.notify_stage_change` строит ссылки из `gitea_public_url`(fallback `gitea_url`)+`gitea_owner`; литералы удалены (AC-1/FR-1 A1) | `test_host_config_keys::test_stage_change_link_uses_public_url_and_owner`/`_falls_back_to_gitea_url`/`_hardcoded_base_removed_from_source` | PASS |
-| TC-04 | Env агент-процесса (launcher ×2): HOME+git-идентичность из settings, дефолты прежние (AC-1/AC-2/FR-1 A2) | `test_host_config_keys::test_agent_git_env_reads_settings`/`_default_identity_matches_previous_hardcode`/`_preserves_ambient_environ`/`test_both_launcher_sites_use_the_helper` | PASS |
-| TC-05 | Env `self_deploy`/`post_deploy`: HOME+идентичность из settings, литералы удалены (AC-1/AC-2/FR-1 A3–A4) | `test_host_config_keys::test_system_actor_envs_read_settings` | PASS |
-| TC-06 | Структурная проверка `docker-compose.yml`: интерполяция `${VAR:-default}`, `group_add` ×3 (ORCH-040) (AC-2/AC-6) | `test_infra_parametrization::test_compose_interpolation_defaults_match_production_values`/`_group_add_docker_gid_on_all_three_services`/`_uid_gid_home_move_as_one_group`/`_ports_parametrised`/`_container_layout_paths_stay_constant`/`_no_raw_host_paths` | PASS |
-| TC-07 | `Dockerfile`: uid/gid/username/home через `ARG`; CMD-порт по ADR (AC-2/AC-6) | `test_infra_parametrization::test_dockerfile_useradd_parametrised_via_args`/`test_dockerfile_cmd_stays_exec_form_8500` | PASS |
-| TC-08 | Полнота `.env.example`: все новые ключи, секреты — плейсхолдеры; deploy-hook `REPO` env-override (AC-5/AC-6) | `test_infra_parametrization::test_env_example_contains_all_new_keys`/`_contains_start_mandatory_keys`/`_secrets_are_placeholders_only`/`test_deploy_hook_repo_is_env_overridable` | PASS |
-| TC-09 | Генератор секретов: разные значения, ≥32 байта, не затирает `.env` молча (AC-5/FR-4/NFR-3) | `test_secrets_gen::test_secret_is_cryptorandom_64_hex`/`test_two_runs_give_different_values`/`test_write_refuses_existing_file_without_force`/`test_write_creates_new_file_and_force_overwrites`/`test_output_keys_consistent_with_env_example`/`test_default_mode_prints_and_touches_no_files`/`test_no_real_secret_committed_anywhere_near` | PASS |
-| TC-10 | Smoke-док + обвязка: `REPLICATION.md` с PASS/FAIL, INFRA.md дополнен, CHANGELOG (AC-3/AC-4/FR-5/FR-7) | `test_replication_smoke::test_replication_doc_has_smoke_procedure_with_pass_fail`/`_covers_secrets_checklist`/`_has_env_map_and_boundaries`/`_is_stateless`/`test_infra_env_map_extended`/`test_changelog_has_orch_101_entry`/`test_gen_secrets_runs_in_safe_mode` | PASS |
-| TC-11 | Инвариант ORCH-058 (A-1): `staging_port` дефолт 8501, guard «≠ прод-порт» (AC-8/FR-1 A5) | `test_host_config_keys::test_staging_port_guard_refuses_prod_port`/`test_staging_port_default_passes_guard`/`test_self_hosting_repo_is_platform_constant` | PASS |
-| TC-12 | Полный регресс `pytest tests/` зелёный на дефолтной конфигурации (AC-2/BR-5) | весь набор — **1764 passed** | PASS |
-
-Соответствие критериям `03-acceptance-criteria.md`: AC-1 (TC-01/02/03/04/05), AC-2 (TC-04/05/06/07/12),
-AC-3 (TC-10 + smoke-прогон выше), AC-4 (TC-10), AC-5 (TC-08/09), AC-6 (TC-06/07/08),
-AC-7 (TC-01/02), AC-8 (TC-11) — все покрыты и зелёные.
-
-## Вывод pytest
-```
-============================= test session starts ==============================
-platform linux -- Python 3.12.13, pytest-8.3.3, pluggy-1.6.0
-rootdir: /repos/_wt/orchestrator/feature_ORCH-101-orch-10-common-smoke
-configfile: pytest.ini
-plugins: cov-5.0.0, anyio-4.13.0, asyncio-0.23.8
-...
-================== 1764 passed, 1 warning in 72.41s (0:01:12) ==================
-```
-(единственный warning — PydanticDeprecatedSince20 в `src/config.py:8`, предсуществующий, не связан с задачей.)
-
-Целевые модули задачи (отдельный прогон):
-```
-tests/test_no_host_hardcodes.py tests/test_host_config_keys.py
-tests/test_infra_parametrization.py tests/test_secrets_gen.py tests/test_replication_smoke.py
-======================== 51 passed, 1 warning in 0.73s =========================
-```
-
-## Итог
-**PASS** — полный регресс зелёный (1764 passed), все 12 TC из `04-test-plan.yaml` выполнены и
-сопоставлены с критериями `03-acceptance-criteria.md`, smoke API read-only (включая блоки
-`serial_gate` и `auto_labels` в `/queue`) и smoke-процедура тиража (AC-3: `REPLICATION.md` +
-безопасный прогон `gen_secrets.py`) зелёные. Задача переходит на `deploy-staging`.

docs/work-items/ORCH-101/14-deploy-log.md

@@ -1,12 +0,0 @@
----
-deploy_status: SUCCESS
-work_item: ORCH-101
-hook_exit_code: 0
-deployed_by: deploy-finalizer
----
-
-# Deploy log — ORCH-036 executable self-deploy
-
-Прод-деплой завершён хост-хуком с exit-code `0` -> `deploy_status: SUCCESS`.
-
-Вердикт зафиксирован детерминированным finalizer'ом (Фаза C), не LLM.

docs/work-items/ORCH-101/15-staging-log.md

@@ -1,37 +0,0 @@
----
-staging_status: SUCCESS
-work_item: ORCH-101
-stage: deploy-staging
-author_agent: deployer
-status: success
-created_at: 2026-06-10
-model_used: claude-opus-4-8
-timestamp: 2026-06-10T18:02:26Z
-base_url: http://localhost:8501
----
-
-# Staging Gate Log
-
-Staging test suite completed against the live `orchestrator-staging` instance (8501),
-run inside the `orchestrator-staging` container via the canonical
-`scripts/staging_check.py --base-url http://localhost:8501 --mode stub`.
-
-**Result: 8/10 checks PASS — exit code 0 → SUCCESS.**
-
-- REAL failed: none — all real checks green.
-- SANDBOX_INFRA failed (waived, ORCH-061): C9a, C9b.
-
-INFRA-WAIVED: C9a Branch appears in orchestrator-sandbox, C9b Analyst job enqueued in staging queue (known sandbox-infra; real checks green)
-VERDICT: SUCCESS (exit 0) — SUCCESS (infra-waived): ['C9a Branch appears in orchestrator-sandbox', 'C9b Analyst job enqueued in staging queue'] are known sandbox-infra checks; all real checks green
-
-## Block detail
-
-- Block A (SMOKE): A1 /health 200, A2 /queue 200, A3 ORCH_STAGING=true — all PASS.
-- Block B (ACCESS): B4 Plane sandbox accessible, B5 Gitea push=true, B6 registry isolation
-  (sandbox present, prod ET/ORCH absent) — all PASS.
-- Block C (E2E, stub): C7 create issue PASS, C8 trigger pipeline PASS,
-  C9a/C9b waived sandbox-infra (depend on SANDBOX bot accounts being project members, not the pipeline).
-- Cleanup: Plane issue deleted (HTTP 204).
-
-Exit code 0 with infra-tolerance enabled (`staging_infra_tolerance_enabled=True`).
-Verdict mapping unchanged: trust the exit code → SUCCESS.

docs/work-items/ORCH-102/00-business-request.md

@@ -1,7 +0,0 @@
-# Business Request: ORCH-10a Lite-тираж: перенос орк+watchdog + полная инструкция донастройки окружения
-
-Work Item ID: ORCH-102
-
-## Description
-
-TBD

docs/work-items/ORCH-102/01-brd.md

@@ -1,211 +0,0 @@
----
-work_item: ORCH-102
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 01 — BRD: ORCH-102 — ORCH-10a Lite-тираж: перенос орк+watchdog + полная инструкция донастройки окружения
-
-Work Item: **ORCH-102** · Repo: **orchestrator** (self-hosting) · Стадия: analysis
-Заказчик: Слава · Эпик: **ORCH-10** (домен D5 «Масштаб», `docs/epics/self-evolution.md`) · Тип: **A — Lite**
-
----
-
-## 1. Бизнес-контекст и проблема
-
-### 1.1. Цель эпика ORCH-10
-Тираж платформы — РАЗДАЧА текущей функциональности нескольким заказчикам **на тест**.
-Решения Владельца 10.06 (приняты как требования, см. §1.4): ДВА типа тиража, ОБА **stateless**
-(наши задачи/данные/секреты НЕ переносим — чистый старт):
-
-- **Тип A (Lite)** — переносим ТОЛЬКО орк+watchdog на новую инфру; окружение
-  (Plane / Gitea / LLM / Telegram) заказчик донастраивает сам **по чёткой инструкции**.
-- **Тип B (Bundled)** — весь стек одним комплектом (отдельная задача эпика, вне ORCH-102).
-
-### 1.2. Проблема, которую закрывает ORCH-102
-Фундамент **10-common (ORCH-101) уже в `main`**: все хост-значения параметризованы env
-(`docker compose config` без переменных = боевое поведение 1:1), секреты выпускаются заново
-(`scripts/gen_secrets.py`), есть smoke-процедура с PASS/FAIL (`docs/operations/REPLICATION.md` §4)
-и анти-регресс `tests/test_no_host_hardcodes.py`. **Технически** платформа разворачивается на
-чужом хосте без правки кода.
-
-**Операционно** — нет: знания размазаны по 4+ документам, каждый из которых писался для
-оператора НАШЕГО хоста, а не для заказчика на чистой инфре:
-
-| Документ | Что покрывает | Чего не хватает для Lite |
-|----------|---------------|--------------------------|
-| `docs/operations/REPLICATION.md` | карта env, секреты, smoke | явно НЕ описывает установку/подключение Plane/Gitea (анти-скоуп Р-5 ORCH-101) |
-| `docs/operations/ONBOARDING.md` | онбординг проекта (статусы/лейблы/репо/kit/реестр) | предполагает уже работающий оркестратор и наш хост |
-| `docs/operations/SETUP_WEBHOOKS.md` | формат вебхуков Plane/Gitea | примеры с боевыми URL (`mva154`), не generic |
-| `docs/operations/INFRA.md` | топология/рестарты нашего хоста | не инструкция «с нуля» |
-
-Заказчик сегодня **не может развернуть Lite без доп-вопросов** — отсутствует единый сквозной
-маршрут «голый хост → работающий конвейер». Главный продукт ORCH-102 — **ИНСТРУКЦИЯ**
-`docs/deployment/LITE_SETUP.md` (golden source в репо), закрывающая этот разрыв.
-
-### 1.3. Установленные факты (проверено по репо, не изобретать)
-- **ORCH-101 смержен** (`git log`: merge #122) — ветка задачи уже содержит фундамент: env-карта
-  §2 REPLICATION.md, `gen_secrets.py`, `.env.example` = канон 100% ключей старта (включая блок
-  `WATCHDOG_*`), smoke §4, тесты `test_no_host_hardcodes/test_infra_parametrization/test_secrets_gen/test_replication_smoke`.
-- **`docker-compose.yml` УЖЕ является compose-подмножеством Lite:** ровно три сервиса —
-  `orchestrator`, `orchestrator-watchdog`, `orchestrator-staging` (последний строго за
-  `profiles: [staging]`); сервисов Plane/Gitea в compose НЕТ. Дефолтный `docker compose up -d`
-  поднимает ровно орк+watchdog. AC-2 достижим без форка compose — нужны фиксация в доке и
-  анти-дрейф тест.
-- **Plane CE не отдаёт webhook через публичный API** — на нашем хосте webhook создан напрямую в
-  PostgreSQL / через UI (`SETUP_WEBHOOKS.md`). Инструкция Lite обязана дать заказчику оба пути
-  (UI и DB) для ЕГО инсталляции Plane.
-- **Точная модель статусов**: 22 канонических имени с группами (источник —
-  `plane_sync._PLANE_NAME_TO_KEY`; таблица — `ONBOARDING.md` §1; создаёт
-  `scripts/onboard_project.py apply`). Код-критичные fail-closed: `Confirm Deploy`, `STOP`
-  (группа `cancelled`); в терминальных группах — только Done/Cancelled/STOP.
-- **Branch protection на `main` нормативно ЗАПРЕЩЁН** (ORCH-009 ADR D10: required-approvals /
-  status-checks ломают PR-merge API merge-актора → ложные HOLD). **Pre-receive хуков в платформе
-  НЕТ** — защита держится конвенцией + скоупом токенов. Формулировка бизнес-запроса
-  «pre-receive хуки» конфликтует с этим нормативом → вопрос архитектору (ТЗ §3.8 А-1);
-  рекомендация: раздел Gitea фиксирует канон (репо+токен+webhook+«protection НЕ включать»).
-- **Гэп watchdog-конфига:** compose читает `.env.watchdog` (`required: false`), но
-  `.env.watchdog.example` в репо НЕТ (есть только `.env.example`/`.env.staging.example`);
-  ключи `WATCHDOG_*` задокументированы внутри `.env.example`. Инструкции нужен однозначный
-  рецепт настройки watchdog-бота (форма — вопрос архитектору А-4).
-- **Платформенные конвенции тиража** (REPLICATION.md §1, нормативно): репо платформы обязан
-  называться `orchestrator` (`SELF_HOSTING_REPO`); имена сервисов/профиля — константы;
-  контейнерный layout (`/app/data`, `/repos`, `/opt/claude-code`) не параметризуется.
-- **Прецедент приёмки smoke**: ORCH-101 AC-3 — воспроизводимость подтверждается прогоном на
-  текущей инфре (staging-песочница `ORCH_STAGING_PORT`=8501 + sandbox-проект), без нового железа.
-
-### 1.4. Решения Владельца (10.06) — приняты как требования
-| # | Решение |
-|---|---------|
-| D-1 | Тиражей ДВА типа: A (Lite) и B (Bundled); ORCH-102 реализует ТОЛЬКО A. |
-| D-2 | Оба типа **stateless**: наши задачи/данные/секреты не переносятся; на целевой инфре чистый старт. |
-| D-3 | Lite = перенос ТОЛЬКО орк+watchdog; окружение (Plane/Gitea/LLM/Telegram) заказчик донастраивает по инструкции. |
-| D-4 | Главный продукт задачи = **инструкция** `docs/deployment/LITE_SETUP.md` — golden source в репо. |
-| D-5 | Зависимость: ORCH-102 ← **10-common (ORCH-101)** — выполнена (смержен), блокеров нет. |
-
----
-
-## 2. Объём (scope)
-
-### 2.1. В объёме
-- **Инструкция `docs/deployment/LITE_SETUP.md`** — полная пошаговая (каждый шаг = команда +
-  проверка), покрывающая сквозной маршрут: предусловия хоста (зависимости, uid/gid) → перенос
-  кода орк+watchdog → конфиг (`.env` с нуля + секреты) → подключение Plane (workspace/проект,
-  точная модель статусов, API-токен, webhook+HMAC) → подключение Gitea (репо, токен, webhook,
-  норматив защиты `main`) → LLM-доступ (claude CLI / ключи моделей) → Telegram (бот трекера +
-  watchdog-бот + chat-id) → запуск compose-подмножества → регистрация проекта
-  (`ORCH_PROJECTS_JSON`, `src/projects.py`) → health-чек → smoke (из 10-common) → траблшутинг.
-- **Фиксация compose-подмножества** (AC-2): документировано и защищено структурным тестом, что
-  дефолтный запуск = ровно орк+watchdog, без Plane/Gitea-контейнеров.
-- **Stateless-нормативы** в инструкции (AC-3): чистая БД, новые секреты, явный запрет переноса
-  наших задач/данных/секретов.
-- **Smoke на чистом окружении** (AC-4): воспроизводимая процедура/чек-лист (переиспользование
-  REPLICATION.md §4) + зафиксированный приёмочный прогон.
-- **Анти-дрейф тесты** структуры/полноты инструкции и compose-подмножества; полный pytest
-  зелёный; `CHANGELOG.md`; перекрёстные ссылки (REPLICATION.md §1 границы, README — по объёму).
-
-### 2.2. Вне объёма (явно, не делать)
-- **Тип B (Bundled)** — весь стек одним комплектом: отдельная задача эпика.
-- **Установка самих Plane / Gitea / Telegram / LLM-аккаунтов** — заказчик ставит по официальной
-  документации вендоров; ORCH-102 покрывает только ПОДКЛЮЧЕНИЕ к оркестратору (анти-скоуп-крип,
-  зеркало Р-5 ORCH-101).
-- **Изменения рантайма/конвейера**: ожидаемый объём — docs+tests; `src/**` не трогается;
-  `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict ключи / схема БД — байт-в-байт.
-- **Перенос данных**: ни БД, ни задач, ни worktree, ни секретов (D-2).
-- **Новая автоматизация** поверх существующих CLI (`gen_secrets.py`, `onboard_project.py`):
-  новые скрипты не вводятся без решения архитектора.
-- **Коммерческая механика раздачи** (доступ заказчика к коду, лицензии, поддержка) —
-  операторский/владельческий уровень; в инструкции — параметризованный источник кода.
-- **Введение pre-receive хуков / branch protection** — запрещено действующим нормативом
-  ORCH-009 ADR D10 (см. §1.3); пересмотр только явным ADR архитектора.
-
----
-
-## 3. Заинтересованные стороны
-- **Владелец (Слава)** — раздаёт платформу заказчикам на тест; принимает инструкцию как продукт.
-- **Заказчик-тестер (новый оператор)** — целевой читатель LITE_SETUP.md: разворачивает Lite на
-  своей инфре без доп-вопросов; технически грамотен (linux/docker), платформу видит впервые.
-- **Оператор текущего прода** — прогоняет приёмочный smoke на staging-песочнице; его прод
-  (общий для enduro-trails) не должен быть затронут.
-- **Будущая задача 10b (Bundled)** — переиспользует разделы Lite-инструкции; границы фиксируются
-  в REPLICATION.md §1.
-
----
-
-## 4. Бизнес-требования (BR)
-
-| ID | Требование | Связь |
-|----|------------|-------|
-| BR-1 | Существует `docs/deployment/LITE_SETUP.md` — **полная пошаговая** инструкция Lite-тиража: по ней человек, не видевший платформу, разворачивает орк+watchdog и донастраивает окружение **без доп-вопросов**; **каждый шаг несёт команду и проверку** (ожидаемый результат / PASS-FAIL). | AC-1, FR-1, D-4 |
-| BR-2 | Инструкция покрывает ВСЕ системы донастройки: Plane (workspace/проект, точная модель статусов — 22 имени с группами, API-токен, webhook+HMAC с учётом ограничения Plane CE), Gitea (репо, токен с нужными scope, per-repo webhook, норматив «branch protection `main` НЕ включать»), LLM (claude CLI: дистрибутив/node/аутентификация/`ORCH_CLAUDE_BIN`/модели), Telegram (бот трекера + ОТДЕЛЬНЫЙ watchdog-бот + получение chat-id), регистрацию проекта (`ORCH_PROJECTS_JSON` через `onboard_project.py`), health-чек, smoke. | AC-1, FR-4 |
-| BR-3 | Разворачивается **compose-подмножество только орк+watchdog**: дефолтный `docker compose up -d` поднимает ровно `orchestrator`+`orchestrator-watchdog`; Plane/Gitea-контейнеров в compose нет; staging-сервис — строго за профилем. Свойство зафиксировано в доке и защищено структурным тестом. | AC-2, FR-2 |
-| BR-4 | **Stateless**: инструкция предписывает чистую БД (создаётся пустой при первом старте), выпуск НОВОГО комплекта секретов (`gen_secrets.py` + чек-лист внешних токенов), и нигде не предписывает перенос наших задач/данных/секретов; в самой доке — только плейсхолдеры, ни одного реального секрета/боевого токена. | AC-3, FR-3 |
-| BR-5 | **Smoke на чистом окружении** существует как воспроизводимая процедура/чек-лист с PASS/FAIL (переиспользование REPLICATION.md §4, без форка); приёмочный прогон выполнен на чистом контуре (минимум — staging-песочница + sandbox-проект, прецедент ORCH-101 AC-3) и зафиксирован в артефактах задачи. | AC-4, FR-5 |
-| BR-6 | **Канон не форкается**: канонические таблицы (модель статусов, карта env, формат вебхуков) инструкция даёт ссылкой на golden source (`ONBOARDING.md`/`REPLICATION.md`/`SETUP_WEBHOOKS.md`) либо с анти-дрейф тестом при неизбежном дублировании; копируемые команды инструкции — generic (плейсхолдеры вместо боевых URL/путей). | AC-1/AC-6, FR-4, NFR-4 |
-| BR-7 | Полный `pytest tests/ -q` зелёный; запись в `CHANGELOG.md`; перекрёстные доки обновлены (REPLICATION.md §1 «границы» — строка Type A → ссылка/статус; README/CLAUDE.md — по фактическому объёму, правило агентов №2/№6). | AC-5, FR-6/FR-7 |
-| BR-8 | Полнота/структура инструкции защищена **структурным pytest** (анти-дрейф, по образцу `tests/test_replication_smoke.py`): исчезновение обязательного раздела/кирпича/env-ключа из дока или дрейф compose-подмножества ломает CI. | AC-6, FR-6 |
-
----
-
-## 5. Нефункциональные требования (NFR)
-
-| ID | Требование |
-|----|------------|
-| NFR-1 | **Self-hosting безопасность:** задача docs+tests; прод-контейнер `orchestrator` не перезапускается; прод-выкат — только штатным конвейером (staging 8501 → ручной Confirm Deploy). |
-| NFR-2 | **Нулевая регрессия:** поведение рантайма не меняется (ожидаемо ноль изменений `src/**`); `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД — байт-в-байт; существующие тесты (включая `test_no_host_hardcodes`, `test_replication_smoke`) остаются зелёными. |
-| NFR-3 | **Секрет-гигиена:** ни в инструкции, ни в тестах — ни одного реального секрета/токена/боевого webhook-секрета; только плейсхолдеры и ссылки на `gen_secrets.py`; security-гейт (ORCH-022) зелёный. |
-| NFR-4 | **Единый источник истины:** инструкция — маршрутизатор поверх канонов, не их копия; неизбежные дубли защищены анти-дрейф тестом (сверка с кодом/каноном импортом, не строкой). |
-| NFR-5 | **Поддерживаемость golden source:** LITE_SETUP.md версионируется в репо и поддерживается агентами при каждой доработке, меняющей шаги тиража (правило агентов №2 — дока в том же PR). |
-| NFR-6 | **Копируемость команд:** каждый код-блок инструкции выполняется на чистом хосте дословно после подстановки явно перечисленных плейсхолдеров (`<...>`); никаких неявных «подразумевается, что…». |
-
----
-
-## 6. Допущения и ограничения
-- **Поддерживаемый контур** (фиксируется в предусловиях инструкции): Linux x86_64, Docker Engine +
-  Compose v2, git, python3; пользователь с правами docker; диск/память по минимальным требованиям
-  (значения уточнит архитектор/инструкция). Иные ОС/архитектуры — вне гарантии Lite.
-- **Заказчик сам ставит** Plane CE, Gitea, заводит Telegram-ботов и LLM-доступ (Claude
-  CLI-аутентификация / ключи) — по официальным докам вендоров; наша инструкция начинается с
-  «системы установлены и доступны по сети».
-- **Имя репо платформы — `orchestrator`** (норматив REPLICATION.md §1 / `SELF_HOSTING_REPO`);
-  инструкция не предлагает его менять.
-- **Источник кода** для заказчика (clone-URL/архив) — решение Владельца; в инструкции —
-  параметризованный шаг (А-6 в ТЗ).
-- «Без доп-вопросов» (AC-1) операционализируется проверяемо: (а) каждый шаг несёт
-  команду+проверку, (б) приёмочный smoke-прогон по инструкции на чистом контуре зафиксирован,
-  (в) траблшутинг покрывает типовые отказы первичной настройки.
-- Терминология бизнес-запроса «pre-receive хуки» трактуется по факту платформы (§1.3):
-  канонический механизм защиты — конвенция + скоуп токенов + запрет branch protection;
-  окончательная формулировка раздела Gitea — за архитектором (А-1).
-
----
-
-## 7. Критерии успеха (резюме; детали — 03-acceptance-criteria.md)
-- AC-1: `docs/deployment/LITE_SETUP.md` — полная пошаговая, человек разворачивает без
-  доп-вопросов (каждый шаг — команда/проверка).
-- AC-2: compose-подмножество только орк+watchdog (без Plane/Gitea-контейнеров).
-- AC-3: stateless — чистая БД, ни одной нашей задачи/секрета.
-- AC-4: smoke на чистом окружении проходит (минимум — воспроизводимая процедура/чек-лист).
-- AC-5: pytest зелёный; CHANGELOG.
-- AC-6 (детализация): анти-дрейф тесты структуры дока/compose; канон не форкается.
-- AC-7 (детализация): self-hosting безопасность, инварианты конвейера не тронуты.
-
----
-
-## 8. Риски (детали — 10-tech-risks.md, заполняет архитектор)
-- R-1 — **Дрейф инструкции**: платформа развивается, шаги устаревают → структурные тесты (BR-8)
-  + правило golden source (NFR-5).
-- R-2 — **Форк канона**: скопированная таблица статусов/env разъедется с кодом → ссылки/анти-дрейф
-  (BR-6, NFR-4).
-- R-3 — **Непроверяемость «без доп-вопросов»** → операционализация через §6 (команда+проверка,
-  smoke-прогон, траблшутинг).
-- R-4 — **Гетерогенность хостов заказчиков** (rootless docker, иной uid, нет node) → явный
-  поддерживаемый контур + предусловия с проверками (`getent group docker`, владение
-  `ORCH_HOST_REPOS_DIR`).
-- R-5 — **Конфликт «pre-receive» с нормативом ADR D10** → вопрос А-1 архитектору; до решения —
-  канон платформы.
-- R-6 — **Утечка секрета через примеры дока** → NFR-3, security-гейт, тест на отсутствие
-  секретоподобных значений.

docs/work-items/ORCH-102/02-trz.md

@@ -1,270 +0,0 @@
----
-work_item: ORCH-102
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 02 — ТЗ (TRZ): ORCH-102 — ORCH-10a Lite-тираж: перенос орк+watchdog + полная инструкция донастройки окружения
-
-Work Item: **ORCH-102** · Repo: **orchestrator** · Стадия: analysis
-
-> ТЗ описывает **что** должно измениться и **где** (документы/контракты/тесты), выведено из BRD и
-> фактического кода (аудит выполнен по репо на ветке задачи; ORCH-101 уже в `main`). **Как**
-> (точная разбивка разделов дока, форма анти-дрейф тестов, исходы вопросов §3.8) — решает
-> архитектор в `06-adr/`.
-
----
-
-## 1. Сводка изменения
-
-**Docs-first задача** (паттерн ORCH-077/092: документы + тесты, рантайм не трогается).
-Создаётся главный продукт — инструкция `docs/deployment/LITE_SETUP.md` (golden source Lite-тиража,
-новый раздел `docs/deployment/`), которая собирает существующие кирпичи 10-common
-(REPLICATION/ONBOARDING/SETUP_WEBHOOKS/INFRA, `gen_secrets.py`, `onboard_project.py`, smoke §4)
-в один сквозной маршрут «голый хост → работающий конвейер» для заказчика. Дополнительно:
-структурные анти-дрейф тесты (полнота дока, compose-подмножество, stateless/секрет-гигиена),
-перекрёстные ссылки и CHANGELOG.
-
-Ожидаемый дифф: `docs/**`, `tests/**`, `CHANGELOG.md` (+ опционально `.env.watchdog.example` —
-исход А-4). **`src/**` — ноль изменений**; конвейер
-(`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД) — байт-в-байт.
-
----
-
-## 2. Задействованные модули / пути
-
-| Путь | Действие |
-|------|----------|
-| `docs/deployment/LITE_SETUP.md` | **создать** — главный продукт (полная пошаговая инструкция Lite; новый каталог `docs/deployment/`) |
-| `docs/operations/REPLICATION.md` | изменить: §1 таблица границ — строка «Type A — Lite» → статус ✅ ORCH-102 + ссылка на LITE_SETUP.md |
-| `tests/test_lite_setup_doc.py` | **создать** — структурные анти-дрейф проверки дока + compose-подмножества (образец: `tests/test_replication_smoke.py`) |
-| `.env.watchdog.example` | создать **по исходу А-4** (канон конфигурации sidecar-watchdog для нового хоста; сейчас примера нет, compose читает `.env.watchdog` `required: false`) |
-| `docs/operations/INFRA.md` | изменить при необходимости: перекрёстная ссылка на deployment-раздел (по фактическому объёму) |
-| `README.md` | изменить: обзорный док — способность Lite-тиража (правило агентов №6: не выдавать открытое за решённое и наоборот) |
-| `CLAUDE.md` | изменить: блок ORCH-102 в паспорте — по фактическому объёму (правило №2) |
-| `CHANGELOG.md` | изменить: запись ORCH-102 |
-| `src/**`, `docker-compose.yml`, `Dockerfile`, `scripts/**` | **НЕ менять** (читаются инструкцией/тестами как источник истины; любое отклонение — только через ADR архитектора) |
-
-Кирпичи, которые инструкция **переиспользует по ссылке** (не форкает, BR-6/NFR-4):
-`docs/operations/REPLICATION.md` (карта env §2, секреты §3, smoke §4),
-`docs/operations/ONBOARDING.md` (статусы §1, слои Gitea/kit/реестр §2–5),
-`docs/operations/SETUP_WEBHOOKS.md` (формат вебхуков, Plane CE-каверза),
-`scripts/gen_secrets.py`, `scripts/onboard_project.py` (plan/apply/verify),
-`.env.example` (канон 100% ключей), `GET /health|/queue|/metrics`.
-
----
-
-## 3. Функциональные требования
-
-### FR-1 — Документ `docs/deployment/LITE_SETUP.md`: состав и форма
-
-Привязка: BR-1, BR-2. Нормативный перечень разделов (порядок = маршрут оператора; финальную
-разбивку/нумерацию решает архитектор, состав — обязательный минимум):
-
-1. **Рамка Lite** — что разворачиваем (орк+watchdog), что заказчик ставит сам (Plane/Gitea/
-   Telegram/LLM), границы vs 10-common vs Bundled (ссылка на REPLICATION.md §1), платформенные
-   конвенции (репо `orchestrator`, имена сервисов, контейнерный layout — не менять).
-2. **Предусловия хоста** («зависимости, uid/gid» из бизнес-запроса): поддерживаемый контур
-   (Linux x86_64, Docker Engine + Compose v2, git, python3); node + дистрибутив claude-code на
-   хосте (`ORCH_HOST_NODE_BIN`, `ORCH_HOST_CLAUDE_CODE_DIR` — пути под маунты); пользователь и
-   владение каталогами: `ORCH_RUN_UID/GID` = uid владельца `ORCH_HOST_REPOS_DIR` (инвариант
-   ORCH-040), `ORCH_DOCKER_GID` — `getent group docker`; ssh-ключи деплой-хука
-   (`ORCH_HOST_SSH_DIR`); свободные порты (`ORCH_DEPLOY_PROD_TARGET_PORT`=8500,
-   `ORCH_STAGING_PORT`=8501). Каждое предусловие — команда проверки.
-3. **Перенос кода орк+watchdog**: получение чекаута репо `orchestrator` на хост в
-   `ORCH_DEPLOY_HOST_REPO_PATH` (источник кода — параметризованный шаг, исход А-6); НИКАКИХ
-   данных/БД/`.env` с боевого хоста (D-2). Watchdog отдельно не переносится — код в `watchdog/`
-   того же репо, образ собирается локально compose'ом.
-4. **Конфигурация**: `.env` строится с нуля от `.env.example` (канон); webhook-секреты —
-   `python3 scripts/gen_secrets.py [--write]`; карта переменных — ссылкой на REPLICATION.md §2;
-   в доке явно — **обязательные ключи нового хоста**: `ORCH_PLANE_API_URL/WEB_URL/WORKSPACE_SLUG`,
-   `ORCH_PLANE_API_TOKEN`, `ORCH_GITEA_URL/PUBLIC_URL/OWNER`, `ORCH_GITEA_TOKEN`, оба
-   webhook-секрета, `ORCH_TELEGRAM_BOT_TOKEN/CHAT_ID`, `ORCH_PROJECTS_JSON` (обязателен:
-   встроенный fallback несёт UUID исходного хоста), хост-параметры `ORCH_AGENT_HOME_DIR`/
-   `ORCH_HOST_*`/`ORCH_RUN_*`/`ORCH_DOCKER_GID`, когерентность портов
-   (`ORCH_DEPLOY_PROD_TARGET_PORT` ⇄ `WATCHDOG_METRICS_URL` ⇄ `ORCH_POST_DEPLOY_BASE_URL`).
-5. **Подключение Plane** (инсталляция заказчика): создать workspace/проект; **точная модель
-   статусов** — 22 канонических имени с группами: создаёт `onboard_project.py apply`, таблица —
-   ссылкой на ONBOARDING.md §1 (без форка; fail-closed `Confirm Deploy`/`STOP` упомянуть явно);
-   выпуск API-токена (Workspace Settings → API tokens) + команда проверки; **webhook+HMAC**:
-   URL `…/webhook/plane`, секрет из `gen_secrets.py`, заголовок `X-Plane-Signature`; каверза
-   Plane CE «webhook не экспонирован в /api/v1» — оба пути (UI и прямой SQL, generic-вариант
-   команд SETUP_WEBHOOKS.md с плейсхолдерами).
-6. **Подключение Gitea** (инсталляция заказчика): репо (`onboard_project.py` или вручную),
-   токен (scope `repo`, `admin:repo_hook`) + проверка, per-repo webhook (events
-   `push`/`pull_request`/`status`, `X-Gitea-Signature`, **ОДИН глобальный секрет на все репо**);
-   норматив защиты `main` — по исходу А-1 (канон: branch protection НЕ включать, ORCH-009 ADR D10).
-7. **LLM-доступ (claude CLI)**: дистрибутив claude-code и node на хосте (пути = маунты compose),
-   `ORCH_CLAUDE_BIN`; аутентификация CLI на хосте (каталог `ORCH_HOST_CLAUDE_DIR` +
-   `ORCH_HOST_CLAUDE_JSON` — монтируются в контейнер; команда первичного логина/проверки —
-   `claude --version` / минимальный вызов); конфигурация моделей — `ORCH_AGENT_MODEL_*` /
-   `ORCH_AGENT_EFFORT_*` (резолв ORCH-41; дефолты канона — в `.env.example`).
-8. **Telegram**: бот трекера (BotFather `/newbot` → `ORCH_TELEGRAM_BOT_TOKEN`), получение
-   `chat_id` (воспроизводимая команда, например через `getUpdates`), проверка `getMe`;
-   **отдельный** watchdog-бот (`WATCHDOG_TG_BOT_TOKEN/CHAT_ID` — независимый канал, C-1
-   ORCH-100, токен орка переиспользовать запрещено) — размещение ключей по исходу А-4
-   (`.env.watchdog`).
-9. **Запуск compose-подмножества**: `docker compose config` (резолв без ошибок) →
-   `docker compose up -d --build` → поднимаются ровно `orchestrator` + `orchestrator-watchdog`
-   (AC-2); staging-профиль — опционально/когда нужен (исход А-5); health-чек:
-   `GET /health` → 200 `"status":"ok"`, `GET /queue`/`GET /metrics` → штатный JSON
-   (`schema_version: 1`).
-10. **Регистрация проекта заказчика**: `onboard_project.py plan → apply → verify`
-    (Plane-проект+статусы+лейблы `autoApprove`/`autoDeploy`/`Bug`, Gitea-репо+webhook, kit,
-    merged `ORCH_PROJECTS_JSON`) → внести строку в `.env` → управляемый рестарт → проверка
-    `/health`+`/queue` (маршрут ONBOARDING.md, ссылкой; в Lite-доке — последовательность команд).
-11. **Smoke** (AC-4): чек-лист REPLICATION.md §4 (шаги 0–5, опционально 6 до `done`) —
-    переиспользовать ссылкой + Lite-специфичные предусловия; критерий «конвейер доехал»:
-    задача в БД → analyst-job в `/queue` → артефакты `01–04` в ветке задачи.
-12. **Stateless-проверка** (AC-3): первый старт создаёт пустую БД (`data/` чист); `GET /queue` —
-    нулевые счётчики, ни одной задачи `ORCH-*`/`ET-*`; явная нормативная строка «данные/задачи/
-    секреты боевого хоста НЕ переносятся».
-13. **Траблшутинг** первичной настройки: минимум — webhook 401/HMAC mismatch; «задача не
-    появилась» (реестр/`ORCH_PROJECTS_JSON`/webhook); claude CLI не аутентифицирован/не найден;
-    `docker.sock` permission denied (`ORCH_DOCKER_GID`); права `/repos` (uid mismatch,
-    ORCH-040/057); Telegram молчит (токен/chat-id). Каждый пункт — симптом → команда
-    диагностики → лечение.
-
-**Форма (NFR-6, BR-1):** каждый шаг — исполняемая команда (fenced code block) + явная проверка
-(«Проверка:» / PASS-FAIL / ожидаемый вывод); все хост-специфичные значения в командах — только
-плейсхолдеры `<...>` или `$ENV_VAR` (боевые `mva154`/`82.22.50.71`/реальные токены — запрещены);
-язык — русский (канон доков платформы).
-
-### FR-2 — Compose-подмножество (AC-2)
-
-Привязка: BR-3. Зафиксировать (в доке + тестом), что Lite-развёртывание использует
-существующий `docker-compose.yml` БЕЗ форка:
-
-- множество сервисов файла — ровно `{orchestrator, orchestrator-watchdog, orchestrator-staging}`;
-- `orchestrator-staging` строго за `profiles: [staging]` → дефолтный `docker compose up -d`
-  поднимает ровно орк+watchdog;
-- сервисов/образов Plane/Gitea в compose НЕТ (и тест не даст появиться молча);
-- форма фиксации (существующий файл vs отдельный lite-вариант) — исход А-2; ТЗ-рекомендация:
-  существующий файл (он уже является подмножеством — факт BRD §1.3), отдельный файл не плодить.
-
-### FR-3 — Stateless-нормативы (AC-3)
-
-Привязка: BR-4. Инструкция обязана: (а) предписывать чистый старт — пустой `data/` (БД создаётся
-`init_db()` при первом старте), `.env` только с нуля; (б) предписывать выпуск НОВЫХ секретов
-(`gen_secrets.py` + чек-лист REPLICATION.md §3.2) и нести норматив «боевые секреты/данные/задачи
-не копируются»; (в) содержать проверку чистоты (FR-1 п.12); (г) сама не содержать реальных
-секретов (NFR-3; проверяется тестом FR-6 и security-гейтом ORCH-022).
-
-### FR-4 — Покрытие донастройки окружения без форка канона (AC-1)
-
-Привязка: BR-2, BR-6. Per-system разделы FR-1 п.5–8 обязаны быть полными (заказчик не ходит за
-ответами вовне репо), при этом канонические данные даются ссылкой на golden source:
-
-| Данные | Golden source | В LITE_SETUP.md |
-|--------|---------------|------------------|
-| 22 статуса + группы | `plane_sync._PLANE_NAME_TO_KEY` / ONBOARDING.md §1 | ссылка + критичные fail-closed имена (`Confirm Deploy`, `STOP`) |
-| Карта env / хост-параметры | REPLICATION.md §2 / `.env.example` | ссылка + список обязательных ключей нового хоста |
-| Формат вебхуков / Plane CE-каверза | SETUP_WEBHOOKS.md | ссылка + generic-команды с плейсхолдерами |
-| Онбординг проекта | ONBOARDING.md / `onboard_project.py` | ссылка + последовательность команд Lite-маршрута |
-| Smoke | REPLICATION.md §4 | ссылка + Lite-предусловия |
-
-Если архитектор решит дублировать таблицу (читаемость) — дубль защищается анти-дрейф тестом
-(сверка импортом из `src/plane_sync.py` / парсингом `.env.example`), не строковой копией.
-
-### FR-5 — Smoke на чистом окружении (AC-4)
-
-Привязка: BR-5. Состав: (а) в LITE_SETUP.md — smoke-раздел (FR-1 п.11) как воспроизводимый
-чек-лист с PASS/FAIL на каждый шаг; (б) приёмочный прогон процедуры на чистом контуре — минимум
-staging-песочница (порт `ORCH_STAGING_PORT`, изолированная БД `./data/staging`) + одноразовый
-sandbox-проект (прецедент ORCH-101 AC-3 / ONBOARDING.md §5.2), без нового железа; (в) результат
-прогона фиксируется в артефактах задачи (`13-test-report.md` / `15-staging-log.md`); (г) прогон
-на реальном новом хосте — желателен, но НЕ требование приёмки (нет железа в контуре задачи).
-
-### FR-6 — Анти-дрейф тесты (BR-8)
-
-Привязка: BR-3, BR-6, BR-8. Новый `tests/test_lite_setup_doc.py` (структурный, без сети/LLM;
-образец — `tests/test_replication_smoke.py`):
-
-1. док существует по канонному пути; несёт обязательные разделы/кирпичи FR-1 (минимум:
-   `gen_secrets.py`, `onboard_project.py`, `docker compose`, `/health`, `/queue`, `/metrics`,
-   `ORCH_PROJECTS_JSON`, webhook-секреты, `X-Plane-Signature`/`X-Gitea-Signature`,
-   `getent group docker`, `Confirm Deploy`/`STOP`, Telegram-боты обоих каналов, маркеры
-   PASS/FAIL/«Проверка»);
-2. каждый env-ключ `ORCH_*`/`WATCHDOG_*`, упомянутый в доке, существует в `.env.example`
-   (анти-опечатка/анти-дрейф канона);
-3. compose-подмножество: парсинг `docker-compose.yml` — ровно 3 сервиса, staging за профилем,
-   ни одного сервиса/образа `plane*`/`gitea*` (AC-2);
-4. stateless/секрет-гигиена: нормативная строка «не копиру…» присутствует; в доке нет
-   секретоподобных значений (эвристика по образцу security-паттернов) и боевых литералов
-   (`mva154`, `duckdns`, `82.22.50.71`) в копируемых код-блоках;
-5. перекрёстность: REPLICATION.md §1 ссылается на LITE_SETUP.md; `CHANGELOG.md` несёт ORCH-102.
-
-Точная нарезка по тест-модулям — за developer (план — `04-test-plan.yaml`); существующие тесты
-не правятся (кроме согласованных структурных дополнений).
-
-### FR-7 — Перекрёстная документация (BR-7)
-
-Привязка: BR-7. REPLICATION.md §1 (строка Type A — Lite → ✅ + ссылка); README.md — способность
-Lite-тиража в обзоре (правило №6); CLAUDE.md — по фактическому объёму; CHANGELOG.md — запись.
-INFRA.md — ссылка на deployment-раздел при необходимости.
-
----
-
-## 3.8. Вопросы архитектору (решаются в `06-adr/`, не в ТЗ)
-
-- **А-1 — «pre-receive хуки» vs норматив ADR D10 (ORCH-009):** бизнес-запрос упоминает
-  pre-receive хуки, но в платформе их нет, а branch protection на `main` нормативно запрещён
-  (ломает PR-merge API merge-актора). Что фиксирует раздел Gitea? Рекомендация ТЗ: канон —
-  репо+токен+webhook+явный норматив «branch protection НЕ включать»; pre-receive не вводить;
-  отклонение — только отдельным ADR с анализом совместимости с merge-актором (ORCH-093/INV-4).
-- **А-2 — форма compose-подмножества:** существующий `docker-compose.yml` (уже = подмножество)
-  + документация/тест vs отдельный `docker-compose.lite.yml`. Рекомендация: существующий, без
-  форка (нулевой дрейф, AC-2 держит тест).
-- **А-3 — размещение дока:** бизнес-запрос фиксирует `docs/deployment/LITE_SETUP.md` (новый
-  раздел `docs/deployment/`); REPLICATION.md живёт в `docs/operations/`. Подтвердить layout
-  (deployment как витрина тиража vs operations) и перекрёстные ссылки; отступление от пути
-  бизнес-запроса — только явным решением.
-- **А-4 — канон watchdog-конфига нового хоста:** compose читает `.env.watchdog`
-  (`required: false`), примера-файла нет; ключи `WATCHDOG_*` канонизированы в `.env.example`.
-  Добавить `.env.watchdog.example` (симметрия с `.env.staging.example`) или документировать
-  шаг «создай `.env.watchdog` с двумя ключами» в LITE_SETUP? Рекомендация: example-файл +
-  упоминание в доке (меньше шансов перепутать файл-носитель).
-- **А-5 — staging-контур в Lite-инструкции:** обязателен ли запуск `orchestrator-staging` у
-  заказчика? Рекомендация: опционален — нужен только если заказчик регистрирует проект
-  `orchestrator` (self-hosting развитие платформы); для «раздачи на тест» базовый контур =
-  prod-инстанс + watchdog; в доке — явная вилка.
-- **А-6 — источник кода для заказчика:** clone-URL (зеркало/доступ к нашему Gitea) vs архив.
-  В доке — параметризованный шаг `git clone <ORCHESTRATOR_GIT_URL>`; конкретику источника
-  фиксирует Владелец (вне репо).
-
----
-
-## 4. Изменения API
-
-Нет. Существующие `GET /health` / `/queue` / `/metrics` переиспользуются инструкцией read-only;
-новые эндпоинты не вводятся.
-
-## 5. Изменения схемы БД
-
-Нет.
-
-## 6. Требования к новым/изменённым QG checks
-
-Нет. `QG_CHECKS`/`check_*`/machine-verdict ключи не меняются. Новые структурные тесты (FR-6) —
-обычный pytest: попадают в существующие гейты (`check_ci_green`/`check_tests_passed`/merge-gate
-re-test/coverage-гейт ORCH-027) автоматически, без регистрации нового QG.
-
-## 7. Совместимость / регресс
-
-- **Нулевая регрессия (NFR-2):** дифф — docs+tests (+опц. `.env.watchdog.example`); рантайм не
-  меняется; kill-switch не требуется (нечего выключать); полный `pytest tests/ -q` зелёный,
-  существующие структурные тесты (`test_no_host_hardcodes`, `test_replication_smoke`,
-  `test_infra_parametrization`, `test_onboarding_*`) не ослабляются.
-- **Обратимость:** удаление дока/тестов возвращает состояние 1:1 (никаких миграций/состояния).
-- **Self-hosting (NFR-1):** прод-контейнер не рестартится; выкат — штатный конвейер
-  (deploy-staging 8501 → ручной Confirm Deploy). Для enduro-trails изменение инертно.
-- **Секрет-гигиена (NFR-3):** в доке/тестах только плейсхолдеры; security-гейт (ORCH-022,
-  `17-security-report.md`) обязан остаться `PASS`.
-- **Инварианты соседних маркеров (правило №9):** ORCH-101 (дефолт = боевое значение; канон
-  `.env.example`; конвенции тиража REPLICATION §1), ORCH-009 (ADR D10 — без branch protection;
-  onboarding-CLI ничего не удаляет), ORCH-100 (независимый Telegram-канал watchdog, C-1),
-  ORCH-040 (uid/gid/HOME группа), ORCH-058 (staging ≠ прод-порт), INV-4 (мерж только через
-  PR-merge API) — инструкция обязана им следовать, а не противоречить.

docs/work-items/ORCH-102/03-acceptance-criteria.md

@@ -1,181 +0,0 @@
----
-work_item: ORCH-102
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 03 — Критерии приёмки (Acceptance Criteria): ORCH-102 — ORCH-10a Lite-тираж
-
-Work Item: **ORCH-102** · Repo: **orchestrator** · Стадия: analysis
-
-Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL**
-(что считается провалом). Любой машинный/ручной reviewer проверяет их буквально по файлам
-репозитория. AC-1…AC-5 — дословно из бизнес-запроса (уточнены до проверяемости);
-AC-6…AC-7 — детализация скоупа (анти-дрейф / инварианты).
-
----
-
-## AC-1 — `docs/deployment/LITE_SETUP.md`: полная пошаговая, без доп-вопросов
-
-**Условие:** инструкция существует и покрывает сквозной маршрут Lite-тиража; каждый шаг —
-команда/проверка; человек, не видевший платформу, разворачивает по ней без доп-вопросов.
-- **PASS:**
-  - файл `docs/deployment/LITE_SETUP.md` существует (путь — по исходу А-3; отклонение от пути
-    бизнес-запроса зафиксировано в ADR задачи);
-  - покрыты ВСЕ разделы нормативного перечня ТЗ §FR-1: рамка Lite/границы; предусловия хоста
-    (зависимости, uid/gid: `ORCH_RUN_UID/GID`, `ORCH_DOCKER_GID` через `getent group docker`,
-    владение `ORCH_HOST_REPOS_DIR`); перенос кода (чекаут `orchestrator`, без данных);
-    конфигурация (`.env` с нуля от `.env.example` + `gen_secrets.py`, обязательные ключи нового
-    хоста включая `ORCH_PROJECTS_JSON`); Plane (workspace/проект, точная модель статусов с
-    fail-closed `Confirm Deploy`/`STOP`, API-токен, webhook+HMAC `X-Plane-Signature` + каверза
-    Plane CE); Gitea (репо, токен со scope, per-repo webhook `X-Gitea-Signature`, один глобальный
-    секрет, норматив защиты `main` по исходу А-1); LLM (claude CLI: дистрибутив/node/аутентификация/
-    `ORCH_CLAUDE_BIN`/модели ORCH-41); Telegram (бот трекера + отдельный watchdog-бот +
-    получение chat-id); запуск compose + health-чек (`/health`, `/queue`, `/metrics`);
-    регистрация проекта (`onboard_project.py` → `ORCH_PROJECTS_JSON` → управляемый рестарт);
-    smoke; stateless-проверка; траблшутинг (≥ 5 типовых отказов: симптом → диагностика → лечение);
-  - **каждый** нормативный шаг несёт исполняемую команду (fenced code block) И явную проверку
-    результата (маркер «Проверка:» / PASS-FAIL / ожидаемый вывод);
-  - копируемые команды generic: хост-специфика только плейсхолдерами `<...>`/`$ENV_VAR`;
-    боевых литералов (`mva154`, `duckdns`, `82.22.50.71`, реальные токены) в код-блоках нет;
-  - «без доп-вопросов» подтверждено операционально: приёмочный smoke-прогон по инструкции
-    выполнен на чистом контуре и зафиксирован (см. AC-4) + траблшутинг покрывает типовые отказы.
-- **FAIL:** файла нет; ИЛИ отсутствует любой нормативный раздел FR-1; ИЛИ есть шаг без
-  команды/проверки («настройте webhook» без как-проверить); ИЛИ в копируемых командах боевые
-  URL/пути/секреты; ИЛИ инструкция отсылает за обязательным шагом во внешний (вне репо) источник.
-
----
-
-## AC-2 — Compose-подмножество: только орк+watchdog
-
-**Условие:** Lite разворачивает ровно `orchestrator`+`orchestrator-watchdog`; Plane/Gitea-контейнеров
-нет; свойство зафиксировано и защищено.
-- **PASS:**
-  - `docker compose config --services` (без активных профилей, пустой env) →
-    ровно `orchestrator` и `orchestrator-watchdog`;
-  - `orchestrator-staging` присутствует в файле строго за `profiles: [staging]` (дефолтный
-    `up -d` его не поднимает);
-  - в `docker-compose.yml` нет сервисов/образов Plane/Gitea (ни `plane*`, ни `gitea*`);
-  - LITE_SETUP.md документирует это свойство (что поднимется после `up -d` и почему staging
-    опционален — исход А-5);
-  - структурный тест compose-подмножества (TC-04) существует и зелёный;
-  - если по исходу А-2 введён отдельный lite-compose — он покрыт тем же тестом, а existing
-    `docker-compose.yml` не форкается без обоснования в ADR.
-- **FAIL:** дефолтный запуск поднимает что-то кроме орк+watchdog; ИЛИ staging вне профиля;
-  ИЛИ в compose появился Plane/Gitea-сервис; ИЛИ свойство не задокументировано; ИЛИ тест
-  отсутствует/красный.
-
----
-
-## AC-3 — Stateless: чистая БД, ни одной нашей задачи/секрета
-
-**Условие:** инструкция предписывает чистый старт и не допускает переноса наших данных/секретов;
-сама дока секретов не содержит.
-- **PASS:**
-  - LITE_SETUP.md нормативно фиксирует: БД создаётся пустой при первом старте (`data/` чист,
-    переносить нечего); `.env`/`.env.staging`/`.env.watchdog` собираются с нуля; явная строка
-    «данные/задачи/секреты боевого хоста НЕ переносятся» (зеркало REPLICATION.md §5);
-  - секреты — только выпуск НОВЫХ: `gen_secrets.py` (webhook) + чек-лист внешних токенов
-    (ссылка на REPLICATION.md §3); ни один шаг не предписывает копирование боевого секрета;
-  - инструкция содержит проверку чистоты развёрнутого инстанса: первый `GET /queue` — нулевые
-    счётчики jobs, ни одной задачи (`ORCH-*`/`ET-*`) в системе;
-  - в самом доке и тестах задачи нет реальных секретоподобных значений (только плейсхолдеры);
-    security-гейт (ORCH-022, `17-security-report.md`) — `PASS`.
-- **FAIL:** любой шаг предписывает/допускает перенос БД/задач/боевого `.env`/секрета; ИЛИ нет
-  нормативной stateless-строки; ИЛИ нет проверки чистоты; ИЛИ в доке обнаружен реальный
-  секрет/боевой токен; ИЛИ security-гейт `FAIL`.
-
----
-
-## AC-4 — Smoke на чистом окружении проходит
-
-**Условие:** smoke существует как воспроизводимая процедура/чек-лист и подтверждён прогоном.
-- **PASS:**
-  - LITE_SETUP.md несёт smoke-раздел: чек-лист с явным PASS/FAIL на каждый шаг, построенный на
-    REPLICATION.md §4 (ссылка, без форка процедуры): конфиг резолвится → `/health` →
-    `/queue`+`/metrics` → тестовый проект (`onboard_project.py plan/apply/verify`) → тестовая
-    задача → «конвейер доехал» (минимум: `analysis` отработала, артефакты `01–04` в ветке);
-  - итог процедуры — однозначный вердикт (все шаги PASS ⇒ тираж PASS);
-  - приёмочный прогон выполнен на чистом контуре — минимум staging-песочница
-    (`ORCH_STAGING_PORT`, изолированная БД `./data/staging`) + одноразовый sandbox-проект
-    (прецедент ORCH-101 AC-3 / ONBOARDING.md §5.2) — и зафиксирован в артефактах задачи
-    (`13-test-report.md` и/или `15-staging-log.md`: дата, контур, шаги, вердикт);
-  - процедура нигде не требует боевых данных/секретов (stateless, согласовано с AC-3).
-- **FAIL:** smoke-раздела нет; ИЛИ шаги без явных PASS/FAIL («посмотреть, что всё ок»); ИЛИ
-  процедура форкает REPLICATION.md §4 с расхождениями; ИЛИ заявленный прогон не зафиксирован в
-  артефактах; ИЛИ прогон провален и не разобран.
-
----
-
-## AC-5 — pytest зелёный; CHANGELOG; перекрёстные доки
-
-**Условие:** регресс чист, документация согласована (правила агентов №2/№6).
-- **PASS:**
-  - полный `pytest tests/ -q` зелёный (включая новые структурные тесты задачи и существующие
-    `test_no_host_hardcodes` / `test_replication_smoke` / `test_infra_parametrization` /
-    `test_onboarding_*` — не ослаблены и не правлены под задачу без согласования);
-  - `CHANGELOG.md` содержит запись ORCH-102;
-  - `docs/operations/REPLICATION.md` §1: строка «Type A — Lite» обновлена (статус ✅/ссылка на
-    LITE_SETUP.md) — границы 10-common vs Lite vs Bundled остаются честными;
-  - `README.md`/`CLAUDE.md` обновлены, если фактический объём того требует (новая операторская
-    способность — Lite-тираж; README не выдаёт нерешённое за решённое и наоборот).
-- **FAIL:** любой тест красный; ИЛИ нет записи в CHANGELOG; ИЛИ REPLICATION.md §1 продолжает
-  числить Lite «отдельной задачей» без ссылки; ИЛИ обзорные доки противоречат факту.
-
----
-
-## AC-6 — Канон не форкается; анти-дрейф защита
-
-**Условие:** инструкция — маршрутизатор поверх golden source'ов, её полнота защищена тестом.
-- **PASS:**
-  - канонические данные (22 статуса, карта env, формат вебхуков, онбординг, smoke) даны ссылкой
-    на golden source (`ONBOARDING.md` §1 / `REPLICATION.md` §2–§4 / `SETUP_WEBHOOKS.md`); при
-    дублировании таблицы — анти-дрейф тест сверяет дубль с источником истины (импорт из
-    `src/plane_sync.py` / парсинг `.env.example`), не строковой копией;
-  - `tests/test_lite_setup_doc.py` существует и проверяет минимум: наличие дока; обязательные
-    кирпичи (ТЗ FR-6.1); согласованность упомянутых env-ключей с `.env.example` (FR-6.2);
-    compose-подмножество (FR-6.3); stateless-норматив и отсутствие боевых литералов/секретов в
-    код-блоках (FR-6.4); перекрёстность REPLICATION→LITE_SETUP и запись CHANGELOG (FR-6.5);
-  - тест детерминирован (повторные прогоны стабильны, без сети/LLM).
-- **FAIL:** таблица статусов/env скопирована без анти-дрейф сверки; ИЛИ тест отсутствует/не
-  ловит исчезновение обязательного раздела/кирпича; ИЛИ упомянутый в доке env-ключ отсутствует
-  в `.env.example`; ИЛИ тест флапает/ходит в сеть.
-
----
-
-## AC-7 — Self-hosting безопасность и неизменность конвейера
-
-**Условие:** задача не дестабилизирует общий прод и не меняет рантайм.
-- **PASS:**
-  - дифф задачи — `docs/**`, `tests/**`, `CHANGELOG.md` (+ согласованные обзорные доки,
-    + `.env.watchdog.example` при исходе А-4); `src/**` не изменён — либо каждое отклонение
-    обосновано в ADR задачи;
-  - `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict ключи / схема БД —
-    без изменений;
-  - прод-контейнер `orchestrator` в рамках задачи не перезапускается; выкат — только штатным
-    конвейером (deploy-staging 8501 → ручной Confirm Deploy);
-  - инструкция не противоречит инвариантам платформы: ADR D10 ORCH-009 (без branch protection),
-    C-1 ORCH-100 (watchdog-бот ≠ бот орка), ORCH-040 (uid/gid/HOME группа), ORCH-058
-    (staging-порт ≠ прод-порт), INV-4 (мерж только через PR-merge API), конвенции тиража
-    REPLICATION.md §1 (репо `orchestrator`, имена сервисов).
-- **FAIL:** немотивированные правки `src/**`/compose/Dockerfile; ИЛИ дифф трогает машину
-  стадий/QG/вердикты/схему БД; ИЛИ рестарт прода вне штатного деплой-пути; ИЛИ шаг инструкции
-  предписывает запрещённое инвариантами (включить branch protection, переиспользовать токен орка
-  для watchdog, скопировать боевой секрет и т.п.).
-
----
-
-## Сводная матрица AC ↔ BR/FR
-
-| AC | Покрывает |
-|----|-----------|
-| AC-1 | BR-1, BR-2 / FR-1, FR-4, NFR-6 |
-| AC-2 | BR-3 / FR-2 |
-| AC-3 | BR-4 / FR-3, NFR-3 |
-| AC-4 | BR-5 / FR-5 |
-| AC-5 | BR-7 / FR-7, NFR-2 |
-| AC-6 | BR-6, BR-8 / FR-6, NFR-4, NFR-5 |
-| AC-7 | NFR-1, NFR-2 / §7 ТЗ (инварианты) |

docs/work-items/ORCH-102/04-test-plan.yaml

@@ -1,146 +0,0 @@
-work_item: ORCH-102
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-10
-model_used: claude-opus-4-8
-title: "ORCH-10a Lite-тираж: инструкция LITE_SETUP + compose-подмножество — план тестов"
-framework: pytest
-scope: >
-  Покрывается: существование и полнота docs/deployment/LITE_SETUP.md (нормативные
-  разделы FR-1, форма «команда+проверка», generic-команды без боевых литералов),
-  согласованность упомянутых env-ключей с каноном .env.example, структурная
-  фиксация compose-подмножества (ровно орк+watchdog, staging за профилем, без
-  Plane/Gitea-сервисов), stateless-нормативы и секрет-гигиена дока, перекрёстные
-  ссылки (REPLICATION.md §1, CHANGELOG), воспроизводимый smoke-чек-лист и его
-  приёмочный прогон на чистом контуре, полный регресс. Вне покрытия: реальный
-  e2e-тираж на новом железе заказчика (заменён прогоном на staging-песочнице —
-  прецедент ORCH-101 AC-3), установка Plane/Gitea как таковых, задача 10b
-  (Bundled), перенос данных (stateless по решению 10.06).
-notes: >
-  Задача docs-first: ожидаемый дифф — docs/** + tests/** + CHANGELOG.md
-  (+ .env.watchdog.example при исходе А-4); src/** не меняется. Имя нового
-  тест-модуля tests/test_lite_setup_doc.py — предложение analyst; developer может
-  переименовать/разбить, сохранив покрытие TC (образец структурных док-тестов —
-  tests/test_replication_smoke.py). Тесты детерминированы, без сети/LLM.
-  Полный регресс tests/ обязан остаться зелёным; STAGE_TRANSITIONS/QG_CHECKS/
-  check_*/machine-verdict не меняются — новые тесты входят в существующие гейты
-  (check_ci_green / merge-gate re-test / coverage-гейт ORCH-027) автоматически.
-  TC-09 — процедурная приёмка AC-4: прогон фиксируется tester'ом в
-  13-test-report.md / 15-staging-log.md, а не автоматизируется в pytest.
-
-tests:
-  - id: TC-01
-    type: unit
-    description: >
-      LITE_SETUP.md существует по канонному пути (docs/deployment/, исход А-3 —
-      синхронизировать с ADR) и несёт ВСЕ нормативные разделы FR-1: рамка/границы
-      Lite, предусловия хоста (зависимости, uid/gid, getent group docker), перенос
-      кода, конфигурация (.env с нуля + gen_secrets.py + ORCH_PROJECTS_JSON),
-      Plane (статусы/токен/webhook+HMAC), Gitea (репо/токен/webhook), LLM
-      (claude CLI), Telegram (трекер + watchdog-бот + chat-id), запуск+health-чек,
-      регистрация проекта, smoke, stateless-проверка, траблшутинг (AC-1 / FR-1).
-    module: tests/test_lite_setup_doc.py
-    expected: PASS
-
-  - id: TC-02
-    type: unit
-    description: >
-      Форма «каждый шаг — команда/проверка»: нормативные разделы содержат fenced
-      code blocks с исполняемыми командами и явные маркеры проверки
-      (PASS/FAIL/«Проверка:»); ключевые кирпичи присутствуют: docker compose,
-      /health, /queue, /metrics, gen_secrets.py, onboard_project.py,
-      X-Plane-Signature, X-Gitea-Signature (AC-1 / FR-1, NFR-6).
-    module: tests/test_lite_setup_doc.py
-    expected: PASS
-
-  - id: TC-03
-    type: unit
-    description: >
-      Согласованность env-канона: каждый ключ ORCH_*/WATCHDOG_*, упомянутый в
-      LITE_SETUP.md, существует в .env.example; обязательный набор нового хоста
-      упомянут явно (ORCH_PROJECTS_JSON, ORCH_PLANE_WEBHOOK_SECRET,
-      ORCH_GITEA_WEBHOOK_SECRET, ORCH_PLANE_API_TOKEN, ORCH_GITEA_TOKEN,
-      ORCH_TELEGRAM_BOT_TOKEN, ORCH_TELEGRAM_CHAT_ID, WATCHDOG_TG_BOT_TOKEN,
-      WATCHDOG_TG_CHAT_ID) (AC-1, AC-6 / FR-1.4, FR-6.2).
-    module: tests/test_lite_setup_doc.py
-    expected: PASS
-
-  - id: TC-04
-    type: unit
-    description: >
-      Compose-подмножество (AC-2): docker-compose.yml парсится; множество сервисов
-      ровно {orchestrator, orchestrator-watchdog, orchestrator-staging};
-      orchestrator-staging строго за profiles: [staging] (дефолтный up -d поднимает
-      ровно орк+watchdog); ни одного сервиса/образа plane*/gitea*; LITE_SETUP.md
-      документирует состав дефолтного запуска (AC-2 / FR-2).
-    module: tests/test_lite_setup_doc.py
-    expected: PASS
-
-  - id: TC-05
-    type: unit
-    description: >
-      Stateless и секрет-гигиена (AC-3): док несёт нормативную строку «боевые
-      данные/задачи/секреты не копируются» и предписывает чистую БД + выпуск
-      новых секретов (gen_secrets.py); проверка чистоты инстанса (первый GET
-      /queue без задач) описана; в копируемых код-блоках нет боевых литералов
-      (mva154, duckdns, 82.22.50.71) и секретоподобных значений — только
-      плейсхолдеры <...>/$ENV_VAR (AC-3 / FR-3, NFR-3).
-    module: tests/test_lite_setup_doc.py
-    expected: PASS
-
-  - id: TC-06
-    type: unit
-    description: >
-      Канон не форкается (AC-6): раздел Plane-статусов ссылается на golden source
-      (ONBOARDING.md §1 / onboard_project.py) и явно упоминает fail-closed имена
-      Confirm Deploy и STOP; при наличии дубля таблицы статусов в доке — дубль
-      сверяется с plane_sync._PLANE_NAME_TO_KEY импортом (22 имени, нулевой
-      дрейф); карта env и smoke даны ссылкой на REPLICATION.md (AC-6 / FR-4,
-      NFR-4).
-    module: tests/test_lite_setup_doc.py
-    expected: PASS
-
-  - id: TC-07
-    type: unit
-    description: >
-      Раздел Gitea соответствует инвариантам платформы: события
-      push/pull_request/status, ОДИН глобальный webhook-секрет на все репо,
-      и норматив защиты main согласован с исходом А-1 ADR задачи (канон: branch
-      protection НЕ включать — ADR D10 ORCH-009; инструкция не предписывает
-      запрещённого) (AC-1, AC-7 / FR-1.6, §3.8 А-1).
-    module: tests/test_lite_setup_doc.py
-    expected: PASS
-
-  - id: TC-08
-    type: unit
-    description: >
-      Перекрёстная документация (AC-5): REPLICATION.md §1 (границы 10-common vs
-      Lite vs Bundled) ссылается на LITE_SETUP.md / отмечает Lite реализованным;
-      CHANGELOG.md содержит запись ORCH-102 (AC-5 / FR-7).
-    module: tests/test_lite_setup_doc.py
-    expected: PASS
-
-  - id: TC-09
-    type: integration
-    description: >
-      Приёмочный smoke-прогон по LITE_SETUP.md на чистом контуре (минимум:
-      staging-песочница ORCH_STAGING_PORT с изолированной БД ./data/staging +
-      одноразовый sandbox-проект; прецедент ORCH-101 AC-3): чек-лист REPLICATION
-      §4 шаги 0–5 — конфиг резолвится, /health 200, /queue+/metrics штатны,
-      onboard verify зелёный, тестовая задача дошла до артефактов 01–04; вердикт
-      и контур зафиксированы в 13-test-report.md / 15-staging-log.md. Процедурная
-      приёмка (исполняет tester по чек-листу), не pytest-модуль (AC-4 / FR-5).
-    module: tests/manual/lite-smoke-checklist (процедура; протокол в 13/15)
-    expected: PASS
-
-  - id: TC-10
-    type: integration
-    description: >
-      Полный регресс: pytest tests/ -q зелёный; существующие структурные тесты
-      (test_no_host_hardcodes, test_replication_smoke, test_infra_parametrization,
-      test_onboarding_*) не ослаблены/не правлены под задачу; дифф не трогает
-      src/** (или каждое отклонение обосновано ADR), STAGE_TRANSITIONS/QG_CHECKS/
-      machine-verdict/схему БД (AC-5, AC-7 / NFR-2).
-    module: tests/
-    expected: PASS

docs/work-items/ORCH-102/06-adr/ADR-001-lite-setup-doc-canon.md

@@ -1,298 +0,0 @@
----
-work_item: ORCH-102
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# ADR-001: Канон Lite-тиража — `docs/deployment/LITE_SETUP.md`, исходы А-1…А-6, анти-дрейф контур
-
-Work Item: **ORCH-102** — ORCH-10a Lite-тираж: перенос орк+watchdog + полная инструкция донастройки окружения
-Стадия: **architecture**
-Сквозная регистрация: **`docs/architecture/adr/adr-0037-lite-replication-canon.md`**
-(новый docs-раздел `docs/deployment/`, новый канонический example-файл и нормативы тиражной
-инсталляции — кросс-каттинг для всех будущих задач эпика ORCH-10 и для агентов, меняющих шаги тиража).
-
-## Статус
-Proposed
-
-## Контекст
-
-Эпик ORCH-10 (D5 «Масштаб»), тип **A — Lite**: заказчик-тестер разворачивает на своей инфре
-ТОЛЬКО орк+watchdog, окружение (Plane/Gitea/LLM/Telegram) донастраивает сам по инструкции.
-Решения Владельца 10.06 (BRD §1.4): оба типа тиража stateless (D-2), главный продукт ORCH-102 —
-**инструкция** `docs/deployment/LITE_SETUP.md` (D-4).
-
-Факты, сверенные с кодом/репо на ветке задачи:
-
-- **Фундамент 10-common (ORCH-101) в `main`** (adr-0036): хост-значения параметризованы
-  (`${VAR:-default}`, «дефолт = боевое значение»), секреты выпускаются заново
-  (`scripts/gen_secrets.py`), smoke с PASS/FAIL — `docs/operations/REPLICATION.md` §4,
-  анти-регресс `tests/test_no_host_hardcodes.py` (центральный список `FORBIDDEN` + хелпер
-  `find_violations`). Технически платформа разворачивается без правки кода; операционно
-  единого маршрута для заказчика нет (знания в 4 operations-доках, писанных для НАШЕГО хоста).
-- **`docker-compose.yml` уже является Lite-подмножеством:** ровно 3 сервиса —
-  `orchestrator`, `orchestrator-watchdog`, `orchestrator-staging`; staging строго за
-  `profiles: [staging]`; сервисов/образов Plane/Gitea нет. Дефолтный `docker compose up -d`
-  поднимает ровно орк+watchdog. Свойство нигде не зафиксировано и ничем не защищено.
-- **Гэп канона watchdog-конфига:** compose читает `.env.watchdog`
-  (`env_file: {path: .env.watchdog, required: false}`), но example-файла нет (есть только
-  `.env.example` / `.env.staging.example`). Ключи `WATCHDOG_*` (19 шт., дефолты =
-  `watchdog/config.py`) задокументированы внутри `.env.example` — однако sidecar-контейнер
-  читает ТОЛЬКО `.env.watchdog`: ключ, положенный оператором в `.env`, для watchdog **инертен**
-  (в `.env` его видит лишь контейнер орка через его `env_file`). Двусмысленность файла-носителя —
-  реальная ловушка первичной настройки.
-- **«Pre-receive хуки» из бизнес-запроса конфликтуют с действующим нормативом:** ORCH-009
-  ADR-001 **D10** — branch protection на `main` НЕ включать (required-approvals/status-checks →
-  405/409-класс отказов `merge_pr` → ложные HOLD, класс инцидента ORCH-063); merge-актор работает
-  только через Gitea PR-merge API (INV-4, `src/merge_gate.py`). Pre-receive хуков в платформе нет;
-  защита `main` — конвенция (агенты не пушат `main`) + скоуп токенов.
-- **Парсер YAML доступен тестам** (`yaml.safe_load` уже используется в
-  `tests/test_infra_parametrization.py::_compose_services`) — структурный тест
-  compose-подмножества не требует новых зависимостей.
-- Прецедент приёмки smoke без нового железа: ORCH-101 AC-3 — staging-песочница
-  (`ORCH_STAGING_PORT`=8501, изолированная БД `./data/staging`) + sandbox-проект
-  (ONBOARDING.md §5, журнал smoke-прогонов).
-
-Задача — **docs+tests** (паттерн ORCH-077/092): `src/**`, `docker-compose.yml`, `Dockerfile`,
-`scripts/**` читаются как источник истины и НЕ меняются; конвейер
-(`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД) — байт-в-байт.
-
-## Решение
-
-### Сводка
-
-Создаётся новый docs-раздел **`docs/deployment/`** (витрина тиража) с golden source
-**`docs/deployment/LITE_SETUP.md`** — сквозной маршрут «голый хост → работающий конвейер» из 13
-нормативных разделов (D2), собирающий кирпичи 10-common ссылками, без форка канона. Compose не
-форкается (D4); канон watchdog-конфига закрывается новым **`.env.watchdog.example`** (D5);
-раздел Gitea фиксирует действующий норматив D10 — branch protection НЕ включать, pre-receive не
-вводить (D3). Полнота/гигиена дока и compose-подмножество защищаются структурным
-`tests/test_lite_setup_doc.py` (D8). Рантайм не трогается; исходы всех вопросов ТЗ §3.8 — ниже.
-
-### D1 (исход А-3) — Размещение: новый раздел `docs/deployment/`, путь бизнес-запроса подтверждён
-
-**Решение: `docs/deployment/LITE_SETUP.md`, как зафиксировано Владельцем (D-4).** Семантика
-разделов: `docs/deployment/` — «как развернуть платформу У СЕБЯ» (читатель — внешний
-оператор/заказчик, платформу видит впервые); `docs/operations/` — «как эксплуатировать НАШ прод»
-(читатель — оператор текущего хоста). `REPLICATION.md` остаётся в `docs/operations/` — это
-runbook фундамента 10-common, исторический якорь ORCH-101, к пути прибит
-`tests/test_replication_smoke.py`; перенос дал бы правку чужого артефакта без выгоды.
-Перекрёстные ссылки обе стороны: REPLICATION.md §1 (строка Type A — Lite → ✅ ORCH-102 + ссылка
-на LITE_SETUP.md) и LITE_SETUP.md §1 (границы — ссылкой на REPLICATION.md §1). INFRA.md получает
-ссылку на deployment-раздел (по фактическому объёму, FR-7).
-
-Привязка: FR-1, FR-7, AC-1, AC-5.
-
-### D2 (FR-1) — Нормативная структура LITE_SETUP.md: 13 разделов, форма «команда + проверка»
-
-**Решение: фиксированная нумерация `## N. <Название>`, порядок = маршрут оператора** (состав —
-обязательный минимум FR-1; анти-дрейф тест ассертит наличие и порядок заголовков):
-
-| § | Раздел | Ключевое содержимое (норматив) |
-|---|--------|--------------------------------|
-| 1 | Рамка Lite | что разворачиваем (орк+watchdog); что заказчик ставит сам; границы vs 10-common/Bundled — ссылка REPLICATION.md §1; платформенные конвенции (репо `orchestrator`, имена сервисов, контейнерный layout — не менять) |
-| 2 | Предусловия хоста | контур: Linux x86_64, Docker Engine + Compose v2, git, python3, node + дистрибутив claude-code; `ORCH_RUN_UID/GID` = uid владельца `ORCH_HOST_REPOS_DIR` (ORCH-040), `ORCH_DOCKER_GID` ← `getent group docker`; ssh (`ORCH_HOST_SSH_DIR`); свободные порты 8500/8501; **каждое предусловие — команда проверки** |
-| 3 | Перенос кода | `git clone <ORCHESTRATOR_GIT_URL>` в `ORCH_DEPLOY_HOST_REPO_PATH` (D7); НИКАКИХ данных/БД/`.env` с боевого хоста; watchdog отдельно не переносится (код в `watchdog/` того же репо) |
-| 4 | Конфигурация | `.env` с нуля от `.env.example` (канон); `python3 scripts/gen_secrets.py [--write]`; карта env — ссылка REPLICATION.md §2; явный список обязательных ключей нового хоста (вкл. `ORCH_PROJECTS_JSON`); `.env.watchdog` от `.env.watchdog.example` (D5); когерентность портов `ORCH_DEPLOY_PROD_TARGET_PORT` ⇄ `WATCHDOG_METRICS_URL` ⇄ `ORCH_POST_DEPLOY_BASE_URL` |
-| 5 | Подключение Plane | workspace/проект; 22 статуса с группами — создаёт `onboard_project.py apply`, таблица ссылкой ONBOARDING.md §1; явно — fail-closed `Confirm Deploy`/`STOP`; API-токен + проверка `curl`; webhook+HMAC: URL `…/webhook/plane`, `X-Plane-Signature`, каверза Plane CE — оба пути (UI и SQL), generic-команды по образцу SETUP_WEBHOOKS.md с плейсхолдерами |
-| 6 | Подключение Gitea | репо (`onboard_project.py` или вручную); токен scope `repo`,`admin:repo_hook` + проверка; per-repo webhook (`push`/`pull_request`/`status`, `X-Gitea-Signature`, ОДИН глобальный секрет); **норматив D3: branch protection НЕ включать** |
-| 7 | LLM (claude CLI) | дистрибутив claude-code и node на хосте = источники маунтов (`ORCH_HOST_CLAUDE_CODE_DIR`/`ORCH_HOST_NODE_BIN`); аутентификация CLI (`ORCH_HOST_CLAUDE_DIR`/`ORCH_HOST_CLAUDE_JSON`); проверка `claude --version`; модели — `ORCH_AGENT_MODEL_*`/`ORCH_AGENT_EFFORT_*` (резолв ORCH-41, дефолты — `.env.example`) |
-| 8 | Telegram | бот трекера (BotFather → `ORCH_TELEGRAM_BOT_TOKEN`), `chat_id` через `getUpdates`, проверка `getMe`; **отдельный** watchdog-бот → `.env.watchdog` (C-1 ORCH-100: токен орка переиспользовать ЗАПРЕЩЕНО) |
-| 9 | Запуск | `docker compose config` → `up -d --build` → ровно `orchestrator`+`orchestrator-watchdog` (D4); health-чек `GET /health` → 200 `"status":"ok"`, `/queue`+`/metrics` → штатный JSON (`schema_version: 1`); **вилка staging (D6)** |
-| 10 | Регистрация проекта | `onboard_project.py plan → apply → verify` (статусы+лейблы `autoApprove`/`autoDeploy`/`Bug`, репо+webhook, kit, merged `ORCH_PROJECTS_JSON`) → строка в `.env` → управляемый рестарт → `/health`+`/queue`; маршрут — ссылка ONBOARDING.md, в доке — последовательность команд Lite |
-| 11 | Smoke | чек-лист REPLICATION.md §4 (шаги 0–5, опционально 6 до `done`) ссылкой + Lite-предусловия; критерий «конвейер доехал»: задача в БД → analyst-job в `/queue` → артефакты `01–04` в ветке |
-| 12 | Stateless-проверка | первый старт = пустая БД (`data/` чист); `GET /queue` — нулевые счётчики, ни одной задачи `ORCH-*`/`ET-*`; нормативная строка «данные/задачи/секреты боевого хоста НЕ переносятся» |
-| 13 | Траблшутинг | ≥ 5 отказов, каждый «симптом → команда диагностики → лечение»: webhook 401/HMAC mismatch; задача не появилась (реестр/`ORCH_PROJECTS_JSON`/webhook); claude CLI не найден/не аутентифицирован; docker.sock permission denied (`ORCH_DOCKER_GID`); права `/repos` (uid mismatch, ORCH-040/057); Telegram молчит |
-
-**Форма (нормативно, NFR-6/BR-1):** (а) каждый нормативный шаг = fenced-команда + явная проверка
-(маркер «Проверка:» / PASS/FAIL / ожидаемый вывод); (б) хост-специфика в fenced-блоках — ТОЛЬКО
-плейсхолдеры `<...>`/`$ENV_VAR`; боевые литералы (`mva154`, `duckdns`, `82.22.50.71`, реальные
-токены) запрещены; дефолты хост-переменных НЕ копируются в док — ссылка на карту
-REPLICATION.md §2 (иначе fenced-скан D8 и форк канона); (в) язык — русский; (г) футер дока несёт
-норматив сопровождения (NFR-5: меняешь шаги тиража → обнови LITE_SETUP.md в том же PR,
-правило агентов №2).
-
-Привязка: FR-1, FR-3, FR-4, AC-1, AC-3.
-
-### D3 (исход А-1) — Раздел Gitea: канон D10, pre-receive НЕ вводить
-
-**Решение: раздел Gitea фиксирует канон платформы — репо + токен (scope `repo`,
-`admin:repo_hook`) + per-repo webhook + нормативная рамка «branch protection на `main` НЕ
-включать».** Формулировка бизнес-запроса «pre-receive хуки» трактуется по намерению («защита
-`main`») и закрывается действующей моделью: мерж — только через Gitea PR-merge API под токеном
-орка (INV-4, `src/merge_gate.py`); агенты не пушат `main` (конвенция + скоуп токенов).
-Pre-receive хуки НЕ вводятся: это server-side механизм инсталляции Gitea заказчика, платформа
-его не несёт и не проверяет; required-approvals/status-checks дали бы 405/409-класс отказов
-`merge_pr` → ложные HOLD (ORCH-009 ADR-001 D10, инцидент ORCH-063). В §13 (траблшутинг) —
-симптом «PR не мержится / HOLD» с первой проверкой «не включена ли branch protection».
-Пересмотр — только отдельным ADR с анализом совместимости с merge-актором (ORCH-093/INV-4).
-
-Привязка: BRD §1.3/§6, FR-1 п.6, AC-7.
-
-### D4 (исход А-2) — Compose: существующий файл, без lite-форка; свойство держит тест
-
-**Решение: `docker-compose.yml` НЕ форкается** — он уже является Lite-подмножеством (факт из
-контекста). Отдельный `docker-compose.lite.yml` отвергнут: второй файл = вторая правда =
-поверхность дрейфа (зеркало решения D9 ORCH-101 «без скрипта-обвязки»). Свойство фиксируется
-в LITE_SETUP.md §9 и защищается тестом (D8, TC-04) через `yaml.safe_load` (паттерн
-`tests/test_infra_parametrization.py::_compose_services`):
-
-- `set(services) == {"orchestrator", "orchestrator-watchdog", "orchestrator-staging"}`;
-- `services["orchestrator-staging"]["profiles"] == ["staging"]`;
-- множество сервисов без `profiles` (= дефолтный `up -d`) — ровно
-  `{"orchestrator", "orchestrator-watchdog"}`;
-- ни в имени сервиса, ни в `image:`/`container_name:` нет подстрок `plane`/`gitea`
-  (анти-появление молча).
-
-Привязка: FR-2, AC-2, BR-3.
-
-### D5 (исход А-4) — `.env.watchdog.example`: создать; key-set синхронизирован тестом
-
-**Решение: создать `.env.watchdog.example`** — третий канонический env-example
-(симметрия `.env.example`/`.env.staging.example`), единственное разрешённое отклонение диффа от
-docs+tests (предусмотрено ТЗ §2). Нормативное содержимое:
-
-- **полный набор ключей `WATCHDOG_*` — ровно тот же, что блок `WATCHDOG_*` в `.env.example`**
-  (key-set equality, 19 ключей; значения = дефолты канона/`watchdog/config.py`,
-  токены — пустые плейсхолдеры);
-- шапка-комментарий: семантика файла-носителя — sidecar-контейнер читает ТОЛЬКО `.env.watchdog`
-  (compose `env_file: required: false`; отсутствие файла не ломает `up`; нет токена → fail-safe:
-  логи без отправки); **ключ `WATCHDOG_*` в `.env` для sidecar инертен**;
-- норматив C-1 (ORCH-100): свой бот, независимый канал; токен орка переиспользовать запрещено;
-- когерентность порта: `WATCHDOG_METRICS_URL` следует за `ORCH_DEPLOY_PROD_TARGET_PORT`;
-- «не коммить реальный `.env.watchdog`» (зеркало шапки `.env.staging.example`).
-
-Анти-дрейф (D8, TC-02b): `keys(.env.watchdog.example) == {k ∈ keys(.env.example) |
-k.startswith("WATCHDOG_")}` — появление нового ключа watchdog в каноне без обновления example
-(и наоборот) ломает CI. Это дубль по необходимости, защищённый сверкой парсингом, не строкой
-(NFR-4). LITE_SETUP.md §4/§8 предписывают `cp .env.watchdog.example .env.watchdog` + два токена.
-
-Привязка: FR-1 п.4/п.8, FR-6.2, AC-1, AC-7 (C-1).
-
-### D6 (исход А-5) — Staging-контур в Lite: опционален, явная вилка
-
-**Решение: базовый Lite-контур = prod-оркестратор (8500) + watchdog; `orchestrator-staging`
-НЕ обязателен.** Staging нужен ТОЛЬКО если заказчик регистрирует проект `orchestrator`
-(self-hosting развитие самой платформы у себя): стадия `deploy-staging` орка требует
-песочницу 8501 (`.env.staging` от `.env.staging.example`, изолированная БД `./data/staging`,
-guard ORCH-058: staging-порт ≠ прод-порт — fail-closed). Для целевого сценария «раздача на
-тест» (заказчик гоняет СВОИ проекты) staging не участвует. В §9 — явная вилка двумя ветками
-с командами; дефолтная ветка — без staging.
-
-Привязка: FR-1 п.9, AC-2 (staging за профилем), ТЗ §3.8 А-5.
-
-### D7 (исход А-6) — Источник кода: параметризованный шаг
-
-**Решение: шаг §3 — `git clone <ORCHESTRATOR_GIT_URL> <ORCH_DEPLOY_HOST_REPO_PATH>`** (плюс
-опциональный `--branch <тег/срез>`). Конкретный канал дистрибуции (зеркало, доступ к нашему
-Gitea, архив) — решение Владельца ВНЕ репо (коммерческая механика — анти-скоуп BRD §2.2);
-док не хардкодит наш Gitea-URL (это же требует NFR-3/fenced-скан). Плейсхолдер
-`<ORCHESTRATOR_GIT_URL>` включён в перечень подстановок §3.
-
-Привязка: FR-1 п.3, BRD §6, ТЗ §3.8 А-6.
-
-### D8 (FR-6) — Анти-дрейф контур: `tests/test_lite_setup_doc.py`
-
-**Решение: один структурный модуль, детерминированный, без сети/LLM/subprocess** (образец —
-`tests/test_replication_smoke.py`). Нормативные семейства проверок (точная нарезка по
-тест-функциям — за developer, `04-test-plan.yaml`):
-
-| TC | Проверка | Механика |
-|----|----------|----------|
-| TC-01 | Док существует; 13 нормативных разделов D2 присутствуют **в заданном порядке** | regex по заголовкам `^## N\.` |
-| TC-02 | Обязательные кирпичи FR-6.1: `gen_secrets.py`, `onboard_project.py`, `docker compose`, `/health`, `/queue`, `/metrics`, `ORCH_PROJECTS_JSON`, оба webhook-секрета, `X-Plane-Signature`/`X-Gitea-Signature`, `getent group docker`, `Confirm Deploy`/`STOP`, оба Telegram-канала, маркеры PASS/FAIL/«Проверка» | подстроки |
-| TC-02b | Key-sync `.env.watchdog.example` ⇄ блок `WATCHDOG_*` `.env.example` (D5) | парсинг строк `^KEY=` обоих файлов, равенство множеств |
-| TC-03 | Каждый токен `\b(ORCH\|WATCHDOG)_[A-Z0-9_]+\b` из дока существует ключом в `.env.example` (канон 100% ключей, ORCH-101) | regex по доку + парсинг `.env.example` |
-| TC-04 | Compose-подмножество (D4): 3 сервиса, staging за профилем, дефолтный up = орк+watchdog, нет `plane*`/`gitea*` | `yaml.safe_load` |
-| TC-05 | Stateless/гигиена: нормативная строка «не перенос…» присутствует; **в fenced-блоках** нет литералов центрального списка `FORBIDDEN` (импорт из `tests/test_no_host_hardcodes.py`, НЕ копия — один источник истины) и секретоподобных значений (эвристика: hex/base64 ≥ 32 симв., не плейсхолдер) | выделение fenced-блоков + `find_violations`/эвристика |
-| TC-06 | Перекрёстность: `REPLICATION.md` §1 ссылается на `LITE_SETUP.md`; `CHANGELOG.md` несёт `ORCH-102` | подстроки |
-
-Скоуп секрет/литерал-скана — **только fenced-блоки** (копируемое); проза дока дефолтов не
-дублирует (D2-форма, п. б) — поэтому полнодокументный скан не нужен и не даёт ложно-красных.
-Существующие тесты (`test_no_host_hardcodes`, `test_replication_smoke`,
-`test_infra_parametrization`, `test_onboarding_*`) не ослабляются; новые тесты попадают в
-существующие гейты (`check_ci_green`/`check_tests_passed`/merge-gate re-test/coverage ORCH-027)
-автоматически — новый QG НЕ регистрируется (ТЗ §6).
-
-Привязка: FR-6, BR-8, AC-5, AC-6.
-
-### D9 — Границы изменения; что НЕ делается; 07/08 — N/A
-
-- **Дифф задачи:** `docs/**` (LITE_SETUP.md, правки REPLICATION §1/INFRA/README/CLAUDE.md по
-  объёму), `tests/test_lite_setup_doc.py`, `CHANGELOG.md`, `.env.watchdog.example` (D5).
-  **`src/**`, `docker-compose.yml`, `Dockerfile`, `scripts/**` — ноль изменений**; любое
-  отклонение — только новым ADR (AC-7).
-- `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict ключи/схема БД — байт-в-байт; новых
-  эндпоинтов/флагов/kill-switch нет (выключать нечего — D-4: док и тесты).
-- **`07-infra-requirements.md` / `08-data-requirements.md` — N/A:** топология не меняется (ни
-  контейнера, ни порта, ни маунта), схема БД не меняется (ТЗ §5). Инфра-предусловий нет:
-  приёмочный smoke-прогон (FR-5/AC-4) идёт на СУЩЕСТВУЮЩЕМ контуре — staging-песочница
-  `ORCH_STAGING_PORT`=8501 + одноразовый sandbox-проект (прецедент ORCH-101 AC-3 /
-  ONBOARDING.md §5); прогон на реальном новом хосте желателен, но не требование приёмки.
-- **Self-hosting (NFR-1):** прод-контейнер не рестартится; выкат — штатный конвейер
-  (deploy-staging 8501 → ручной `Confirm Deploy`). Для enduro-trails изменение инертно.
-- Эскалация: `arch:major-change` не требуется (нет новой стадии/компонента/смены БД); ТЗ
-  удовлетворимо без нарушения принципов — возврат в анализ не нужен.
-
-## Альтернативы
-
-- **Разместить инструкцию в `docs/operations/`** — отвергнуто: целевой читатель другой (внешний
-  оператор, не оператор нашего прода); путь `docs/deployment/LITE_SETUP.md` зафиксирован
-  Владельцем (D-4), отступать не от чего (D1).
-- **Перенести REPLICATION.md в `docs/deployment/`** — отвергнуто: правка чужого артефакта и
-  путей `tests/test_replication_smoke.py` без выгоды; перекрёстных ссылок достаточно (D1).
-- **Отдельный `docker-compose.lite.yml`** — отвергнуто: вторая правда о сервисах, дрейф-
-  поверхность; существующий файл уже = подмножество, тест дешевле форка (D4).
-- **Pre-receive хуки / branch protection для «защиты `main`»** — отвергнуто: ломает PR-merge
-  API merge-актора (D10 ORCH-009, ложные HOLD); защита — конвенция + скоуп токенов + INV-4 (D3).
-- **Без `.env.watchdog.example`, шаг «создай файл с двумя ключами» в доке** — отвергнуто:
-  двусмысленность файла-носителя остаётся (ключи канонизированы в `.env.example`, но там для
-  sidecar инертны); example-файл + key-sync тест дешевле и надёжнее прозы (D5).
-- **Скопировать таблицу 22 статусов / карту env в LITE_SETUP.md** — отвергнуто: форк канона
-  (R-2); ссылки на golden source + явное упоминание только fail-closed имён
-  (`Confirm Deploy`/`STOP`) — достаточно (FR-4); дубль допустим только с тест-сверкой
-  парсингом/импортом (прецедент — TC-02b).
-- **Полнодокументный секрет-скан (не только fenced)** — отвергнуто: ложно-красные на прозе
-  («не используйте mva154-значения»); норматив D2(б) выводит дефолты из дока, fenced-скан
-  покрывает всё копируемое (D8).
-
-## Последствия
-
-- **+** Закрывается Type A эпика ORCH-10: заказчик получает единый исполняемый маршрут
-  «голый хост → конвейер» без археологии по 4 докам; Type B (Bundled) строится поверх
-  (переиспользует §2–§8, §11–§13).
-- **+** Compose-подмножество и полнота инструкции из «фактов» становятся CI-гарантиями
-  (TC-01…TC-06); ловушка файла-носителя watchdog-конфига закрыта каноном (D5).
-- **+** Нулевой риск рантайма: docs+tests, конвейер байт-в-байт, kill-switch не нужен.
-- **−** Новый golden source = новая обязанность сопровождения (шаги тиража меняются →
-  LITE_SETUP.md в том же PR; NFR-5) — митигировано футером-нормативом, правилом агентов №2 и
-  структурным тестом, который рвёт CI при дрейфе кирпичей.
-- **−** Дубль ключей `WATCHDOG_*` в двух example-файлах — принят осознанно, защищён key-sync
-  тестом TC-02b (равенство множеств, не строк).
-- **−** Приёмка «без доп-вопросов» на staging-песочнице ≠ прогон на реальном чужом хосте —
-  остаточный риск принят (прецедент ORCH-101 AC-3); зазор сужают чек-команды предусловий §2 и
-  траблшутинг §13.
-- **Откат:** удалить `docs/deployment/`, `tests/test_lite_setup_doc.py`,
-  `.env.watchdog.example`, вернуть строку REPLICATION.md §1 — состояние 1:1, ни миграций,
-  ни состояния (ТЗ §7).
-
-## Ссылки
-
-- BRD: `docs/work-items/ORCH-102/01-brd.md` (решения Владельца D-1…D-5, факты §1.3)
-- TRZ: `docs/work-items/ORCH-102/02-trz.md` (FR-1…FR-7, вопросы §3.8 А-1…А-6)
-- Acceptance: `docs/work-items/ORCH-102/03-acceptance-criteria.md` (AC-1…AC-7)
-- Риски: `docs/work-items/ORCH-102/10-tech-risks.md`
-- Сквозной ADR: `docs/architecture/adr/adr-0037-lite-replication-canon.md`
-- Сверено по коду/репо: `docker-compose.yml` (3 сервиса, `profiles: [staging]`,
-  `env_file: {path: .env.watchdog, required: false}`), `.env.example` (блок `WATCHDOG_*`,
-  19 ключей), `watchdog/config.py` (дефолты), `tests/test_infra_parametrization.py`
-  (`yaml.safe_load`-паттерн), `tests/test_no_host_hardcodes.py` (`FORBIDDEN`,
-  `find_violations`), `tests/test_replication_smoke.py` (образец структурного теста дока),
-  `docs/operations/REPLICATION.md` §1–§5, `docs/operations/ONBOARDING.md` §1/§5,
-  `docs/operations/SETUP_WEBHOOKS.md`
-- Инварианты соседних решений: ORCH-009 ADR-001 D10 (`docs/work-items/ORCH-009/06-adr/…`),
-  adr-0036 (ORCH-101, 10-common), adr-0035 (onboarding), adr-0033 (sidecar-watchdog, C-1
-  ORCH-100), ORCH-040 (uid/gid/HOME), ORCH-058 (staging-порт guard), INV-4 (ORCH-093)

docs/work-items/ORCH-102/10-tech-risks.md

@@ -1,40 +0,0 @@
----
-work_item: ORCH-102
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-10
-model_used: claude-opus-4-8
----
-
-# 10 — Технические риски: ORCH-102 — ORCH-10a Lite-тираж (инструкция + анти-дрейф)
-
-Work Item: **ORCH-102** · Repo: **orchestrator** · Стадия: architecture
-
-> Информационный (гейтом не парсится). Перечисляет риски реализации и их митигейшн.
-> Решения, на которые ссылаются митигейшны (D1…D9), — `06-adr/ADR-001-lite-setup-doc-canon.md`.
-
-## Реестр рисков
-
-| ID | Риск | Вер. | Влия. | Митигейшн |
-|----|------|------|-------|-----------|
-| TR-1 | **Дрейф инструкции**: платформа развивается, шаги LITE_SETUP.md тихо устаревают (новый env-ключ, изменённый маршрут онбординга) | Сред. | Сред. | Структурный `tests/test_lite_setup_doc.py` (D8: кирпичи, env-ключи ⊂ `.env.example`, compose-подмножество, перекрёстность) рвёт CI при дрейфе; футер-норматив NFR-5 + правило агентов №2 («шаги тиража → док в том же PR»); reviewer-ось обзорных доков (правило №6) |
-| TR-2 | **Форк канона**: скопированная в док таблица статусов/env/вебхуков разъезжается с golden source | Низ. | Сред. | D2/FR-4: канон — только ссылками (ONBOARDING §1 / REPLICATION §2–§4 / SETUP_WEBHOOKS); в доке дублируются лишь fail-closed имена (`Confirm Deploy`/`STOP`) и списки обязательных ключей — оба под TC-02/TC-03; единственный структурный дубль (`WATCHDOG_*`) — под key-sync TC-02b |
-| TR-3 | **«Без доп-вопросов» непроверяемо**: реальный заказчик найдёт пробел, который не увидел внутренний прогон | Сред. | Низ. | Операционализация BRD §6: каждый шаг = команда+проверка (TC-01/02), приёмочный smoke-прогон на чистом контуре фиксируется в `13-test-report.md`/`15-staging-log.md`, траблшутинг ≥5 отказов (§13). Остаточные пробелы лечатся правкой golden source штатной задачей |
-| TR-4 | **Гетерогенность хостов заказчиков**: rootless docker, иной uid владельца репо, нет node/claude-code, arm64 | Сред. | Сред. | §2 «Предусловия» с явным поддерживаемым контуром (Linux x86_64, Docker+Compose v2, git, python3, node) и чек-командой на каждое предусловие (`getent group docker`, владение `ORCH_HOST_REPOS_DIR` = `ORCH_RUN_UID`); вне контура — вне гарантии Lite (BRD §6); §13 покрывает типовые отказы (docker.sock gid, uid mismatch ORCH-040/057) |
-| TR-5 | **Заказчик включит branch protection / pre-receive на `main`** вопреки нормативу → ложные HOLD merge-актора на ЕГО инсталляции (класс ORCH-063) | Низ. | Выс. (у заказчика) | D3: явная нормативная рамка в §6 («НЕ включать», основание D10 ORCH-009/INV-4) + симптом в §13 («PR не мержится/HOLD → проверь protection»); для нашего прода риск нулевой (его Gitea не трогается) |
-| TR-6 | **Утечка секрета/боевого литерала** через примеры дока или `.env.watchdog.example` | Низ. | Выс. | NFR-3: только плейсхолдеры; TC-05 — fenced-скан на `FORBIDDEN` (импорт из `test_no_host_hardcodes.py`, один источник истины) + эвристика секретоподобных значений; security-гейт ORCH-022 (`17-security-report.md`) обязан остаться PASS; D2(б): дефолты хост-переменных в док не копируются |
-| TR-7 | **Хрупкость анти-дрейф теста**: ложно-красный CI от безобидной правки прозы → соблазн ослабить тест | Сред. | Низ. | D8: ассерты только на стабильное (заголовки `## N.`, подстроки-кирпичи, парсинг env-ключей, `yaml.safe_load`), запреты — только в fenced-блоках; никаких проверок прозы/формулировок; паттерн уже обкатан (`test_replication_smoke.py` стабилен) |
-| TR-8 | **`.env.watchdog.example` разъезжается** с блоком `WATCHDOG_*` `.env.example` / дефолтами `watchdog/config.py` | Низ. | Низ. | TC-02b: равенство множеств ключей двух файлов; значения = дефолты канона (сверены с `watchdog/config.py` при ревью); полнота самого `.env.example` уже держится тестами ORCH-101 |
-| TR-9 | **Приёмочный smoke на staging-песочнице ≠ голый чужой хост**: средовые эффекты нового железа (сеть, версии docker) не проверены | Сред. | Низ. | Принятый прецедент ORCH-101 AC-3 (без нового железа в контуре задачи; FR-5(г) — прогон на реальном хосте желателен, не блокер); зазор сужают чек-команды §2 и траблшутинг §13; первый реальный тираж — операторски сопровождаемый |
-
-## Сводный вывод
-
-Доминирующий класс — **документационный** (дрейф/полнота/гигиена), систематически закрытый
-структурными тестами (TC-01…TC-06) и нормативом golden source; рантайм-рисков нет — дифф
-docs+tests (+`.env.watchdog.example`), конвейер и `src/**` байт-в-байт (D9), kill-switch не
-требуется. Самый тяжёлый по влиянию риск (TR-5) материализуется только на инсталляции
-заказчика и купирован явным нормативом + траблшутингом. Эскалация `arch:major-change` не
-требуется; возврат в анализ не нужен. **Остаточный риск для self-hosting прод-конвейера —
-минимальный** (прод-контейнер не трогается; выкат — штатно через staging 8501 →
-`Confirm Deploy`).

docs/work-items/ORCH-102/12-review.md

@@ -1,93 +0,0 @@
----
-verdict: APPROVED
-work_item: ORCH-102
-stage: review
-author_agent: reviewer
-status: approved
-created_at: 2026-06-10
-model_used: claude-opus-4-8
-type: review
-work_item_id: ORCH-102
-version: 1
----
-
-# Review ORCH-102 — ORCH-10a Lite-тираж: LITE_SETUP.md + канон watchdog-конфига + анти-дрейф контур
-
-## Summary
-
-PR (`d03e29f`, docs+tests, 2378 строк) реализует все требования ТЗ и решения ADR-001 (D1–D9)
-точно по спецификации; P0/P1 findings отсутствуют. Дифф строго в декларированных границах:
-`docs/**`, `tests/test_lite_setup_doc.py`, `CHANGELOG.md`, `.env.watchdog.example` + `.gitignore`
-(единственное разрешённое отклонение по ADR D5/ТЗ §2). **`src/**`, `docker-compose.yml`,
-`Dockerfile`, `scripts/**` — ноль изменений** (AC-7 PASS, сверено по `git diff --stat`);
-`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД не тронуты.
-
-**Проверено фактически (не по описанию):**
-- Полный регресс: `pytest tests/ -q` → **1789 passed** (включая 25 новых структурных тестов;
-  заявление CHANGELOG «25 структурных тестов» совпадает с фактом). Существующие
-  `test_no_host_hardcodes`/`test_replication_smoke`/`test_infra_parametrization` не ослаблены.
-- **AC-1/FR-1:** `docs/deployment/LITE_SETUP.md` — 13 нормативных разделов D2 в порядке маршрута
-  оператора; каждый исполняемый раздел = fenced-команда + явная «Проверка:»/PASS/FAIL;
-  хост-специфика только плейсхолдерами. Копируемые команды сверены с фактическими контрактами
-  кода: флаги `onboard_project.py` (`plan|apply|verify` + `--name/--repo/--prefix/--stack/
-  --test-cmd/--prod-port/--staging-port/--webhook-url`) — совпадают с argparse скрипта;
-  exit-коды (0/2 = manual-step) — совпадают с docstring/кодом; `gen_secrets.py` печатает именно
-  `ORCH_PLANE_WEBHOOK_SECRET`/`ORCH_GITEA_WEBHOOK_SECRET`; `/metrics` → `schema_version: 1`
-  (`src/metrics.py::SCHEMA_VERSION`); ссылка на шаги 0–5/6 REPLICATION §4 — фактическая нумерация
-  таблицы §4 совпадает. Траблшутинг — 7 отказов (≥5 по AC-1), каждый «симптом → диагностика → лечение».
-- **AC-2/FR-2 (D4):** compose не форкается; TC-04 ассертит ровно 3 сервиса, staging строго за
-  `profiles: [staging]`, дефолтный up = орк+watchdog, анти-`plane*`/`gitea*` — через `yaml.safe_load`.
-- **AC-3/FR-3:** stateless-норматив (§12 + шапка), чистый старт, проверка чистоты через
-  `GET /queue`, секреты только свежевыпущенные; в fenced-блоках и `.env.watchdog.example` —
-  только плейсхолдеры (TC-05 + зеркальный placeholder-тест, токены пустые).
-- **D5:** `.env.watchdog.example` — key-set ровно = блоку `WATCHDOG_*` `.env.example` (19 ключей,
-  сверено; держится TC-02b равенством множеств), шапка несёт семантику файла-носителя, C-1
-  ORCH-100, когерентность порта, do-not-commit; `.env.watchdog` добавлен в `.gitignore`.
-- **AC-6/FR-6 (D8):** канон не форкается — статусы/env/вебхуки/smoke ссылками; «22 статуса»
-  защищено **импортом** `plane_sync._PLANE_NAME_TO_KEY` (не строкой); `FORBIDDEN` — импорт из
-  `test_no_host_hardcodes.py` (один источник истины); секрет-эвристика с негативным самочеком
-  (анти-вечнозелёность). Тесты детерминированы, без сети/LLM/subprocess.
-- **D3 (исход А-1):** §6.4 нормативно запрещает branch protection на `main` (ADR D10 ORCH-009 /
-  INV-4), pre-receive не вводится, ОДИН глобальный webhook-секрет; §13.7 — симптом «HOLD».
-- **Трассировка (TRACEABILITY):** правки чужих маркированных блоков сверены: REPLICATION.md §1
-  (ORCH-101) — ровно предусмотренное закрытие строки «Type A — Lite» → ✅ + ссылка; INFRA.md —
-  аддитивное расширение секрет-норматива на `.env.watchdog`; инварианты ORCH-101/009/100/040/058/
-  INV-4 не нарушены (инструкция им следует, ADR их цитирует). Бонус: дозаполнена пропущенная
-  строка adr-0036 в индексе `docs/architecture/adr/README.md` + max-номер → 0037.
-
-## Findings
-
-### P0 — Blocker
-Нет.
-
-### P1 — Must fix
-Нет.
-
-### P2 — Should fix
-Нет.
-
-### P3 — Nice to have (не блокирует)
-- [ ] `LITE_SETUP.md` §13.3: в fenced-блоке литерал `/usr/bin/claude` — совпадает с канон-дефолтом
-  `ORCH_CLAUDE_BIN` (контейнерный layout, не хост-специфика), но `docker exec orchestrator
-  "$ORCH_CLAUDE_BIN" --version`-форма была бы устойчивее к смене дефолта (правило формы D2(б) —
-  ссылка на канон вместо копии значения).
-- [ ] `tests/test_lite_setup_doc.py` BRICKS: кирпич `"STOP"` как подстрока всего дока слаб
-  (матчится любым словом STOP); фактически заякорен `test_plane_canon_is_linked_not_forked`
-  (STOP внутри тела §5), так что дублирование безвредно — можно убрать из BRICKS или заякорить.
-
-## Документация
-
-**Полностью обновлена в том же PR** (правило №2; ось 4 — PASS):
-- `CHANGELOG.md` — запись ORCH-102 (фактуально точная: 25 тестов, траблшутинг ×7 — сверено);
-- `CLAUDE.md` — блок «Lite-тираж (ORCH-102)»; `README.md` — способность Lite + `docs/deployment/`
-  в структуре; `docs/architecture/README.md` — блок Type A — Lite;
-- ADR: per-work-item `06-adr/ADR-001-lite-setup-doc-canon.md` (D1–D9, исходы А-1…А-6) + сквозной
-  `docs/architecture/adr/adr-0037-lite-replication-canon.md` + индекс ADR обновлён;
-- `docs/operations/REPLICATION.md` §1 и `docs/operations/INFRA.md` — перекрёстные ссылки (FR-7);
-- **ORCH-079 (обзорные доки):** README «Известные ограничения» проверен — пунктов про
-  тираж/Lite в открытом списке не было и нет, закрывать/снимать нечего; противоречий факту нет.
-
-**Handoff для tester (не finding):** AC-4 требует фиксации приёмочного smoke-прогона на чистом
-контуре (staging-песочница + sandbox-проект) в `13-test-report.md` и/или `15-staging-log.md` —
-эти артефакты по конвейеру создаются на стадиях testing/deploy-staging (план — TC-09
-`04-test-plan.yaml`); на стадии review их отсутствие штатно.

docs/work-items/ORCH-102/13-test-report.md

@@ -1,95 +0,0 @@
----
-result: PASS   # PASS | FAIL — машинный вердикт, UPPERCASE
-work_item: ORCH-102
-stage: testing
-author_agent: tester
-status: pass
-created_at: 2026-06-11
-model_used: claude-opus-4-8
-type: test-report
-work_item_id: ORCH-102
----
-
-# Test Report — ORCH-102 — ORCH-10a Lite-тираж: LITE_SETUP.md + канон watchdog-конфига + анти-дрейф контур
-
-## Окружение
-- Python: 3.12.13
-- pytest: 8.3.3 (plugins: cov-5.0.0, anyio-4.13.0, asyncio-0.23.8)
-- Дата: 2026-06-11
-- Worktree: `/repos/_wt/orchestrator/feature_ORCH-102-orch-10a-lite-watchdog`
-- Ветка: `feature/ORCH-102-orch-10a-lite-watchdog` (HEAD `e67c026`)
-- Прогон выполнен в worktree ветки задачи (не в общем `/repos/orchestrator`).
-- Вердикт ревью (`12-review.md`): **APPROVED** (P0/P1 — нет).
-
-## Smoke API (read-only)
-| Проверка | Результат |
-|----------|-----------|
-| `GET /health` | PASS — `{"status":"ok","service":"orchestrator"}` |
-| `GET /status` | PASS — задача ORCH-102 (task 89) на стадии `testing` |
-| `GET /queue` | PASS — отдаёт полезную нагрузку, штатные счётчики |
-| Блок `serial_gate` в `/queue` (ORCH-088) | PASS — присутствует; `orchestrator.active_task = ORCH-102 (testing)`, не заморожен |
-| Блок `auto_labels` в `/queue` (ORCH-089) | PASS — присутствует |
-| `GET /metrics` | PASS — `schema_version: 1` |
-| `GET /health` staging (8501) | PASS — `{"status":"ok","service":"orchestrator"}` |
-
-## Smoke-процедура Lite-тиража (AC-4 / FR-5, TC-09)
-Воспроизводимость smoke-runbook LITE_SETUP.md подтверждена на текущей инфре (read-only, stateless,
-без переноса данных/секретов; прецедент ORCH-101 AC-3). Docs+tests-задача — `src/**` не тронут,
-полноценный e2e на новом железе заказчика заменён прогоном артефактов smoke-цепочки:
-| Шаг smoke (REPLICATION §4 / LITE_SETUP §10–12) | Результат |
-|-----|-----------|
-| `docs/deployment/LITE_SETUP.md` существует по канонному пути (33 КБ, 13 разделов) | PASS |
-| `.env.watchdog.example` существует (канон watchdog-конфига, ADR D5) | PASS |
-| `scripts/gen_secrets.py` запускается в безопасном (print) режиме | PASS — exit 0, файлы не тронуты (`git status` чист) |
-| Webhook-секреты крипто-случайны (64 hex = 32 байта) | PASS — `ORCH_PLANE_WEBHOOK_SECRET`/`ORCH_GITEA_WEBHOOK_SECRET` |
-| Внешние токены/боевые секреты в доке отсутствуют (плейсхолдеры) | PASS (подтверждено TC-05) |
-| Конфиг резолвится, инстанс поднят, health-check зелёный (см. Smoke API) | PASS |
-| `GET /metrics` → `schema_version: 1` | PASS |
-| Compose-подмножество (ровно орк+watchdog, staging за профилем) | PASS — структурно через TC-04 (yaml-парс; `docker` CLI в песочнице tester'а недоступен, свойство фиксируется тестом) |
-
-## Результаты (покрытие TC из `04-test-plan.yaml`)
-
-| TC ID | Описание | Покрывающие тесты | Результат |
-|-------|----------|-------------------|-----------|
-| TC-01 | LITE_SETUP.md существует по канонному пути и несёт ВСЕ 13 нормативных разделов FR-1 (AC-1/FR-1) | `test_lite_setup_doc::test_doc_exists_with_all_13_sections_in_order`, `test_doc_carries_all_mandatory_bricks` | PASS |
-| TC-02 | Форма «каждый шаг — команда/проверка»: fenced-команды + маркеры PASS/FAIL/«Проверка», ключевые кирпичи (AC-1/FR-1, NFR-6) | `test_every_normative_section_carries_commands`, `test_doc_carries_explicit_check_markers` | PASS |
-| TC-03 | Согласованность env-канона: каждый `ORCH_*`/`WATCHDOG_*` в доке есть в `.env.example`; обязательный набор нового хоста явно (AC-1/AC-6/FR-1.4/FR-6.2) | `test_every_env_token_in_doc_exists_in_env_example`, `test_mandatory_new_host_keys_are_explicit`, `test_watchdog_example_keys_sync_with_env_example_block` | PASS |
-| TC-04 | Compose-подмножество: ровно `{orchestrator, orchestrator-watchdog, orchestrator-staging}`, staging за `profiles:[staging]`, без `plane*`/`gitea*` (AC-2/FR-2) | `test_compose_services_are_exactly_the_lite_set`, `test_compose_staging_is_strictly_behind_profile`, `test_compose_has_no_plane_or_gitea_services`, `test_doc_documents_default_up_composition` | PASS |
-| TC-05 | Stateless и секрет-гигиена: нормативная строка «не копируются», чистая БД + новые секреты, проверка чистоты, нет боевых литералов/секретов в код-блоках (AC-3/FR-3/NFR-3) | `test_doc_has_stateless_normative_line`, `test_doc_prescribes_clean_db_and_fresh_secrets`, `test_fenced_blocks_carry_no_forbidden_literals`, `test_fenced_blocks_carry_no_secret_like_values`, `test_secret_heuristic_is_not_evergreen`, `test_watchdog_example_secrets_are_placeholders_only` | PASS |
-| TC-06 | Канон не форкается: статусы ссылкой на ONBOARDING §1 + fail-closed `Confirm Deploy`/`STOP`; «22 статуса» сверены импортом `plane_sync._PLANE_NAME_TO_KEY`; env/smoke ссылкой на REPLICATION (AC-6/FR-4/NFR-4) | `test_plane_canon_is_linked_not_forked`, `test_status_count_claim_matches_plane_sync`, `test_env_map_and_smoke_are_linked_to_replication` | PASS |
-| TC-07 | Раздел Gitea: события `push/pull_request/status`, ОДИН глобальный webhook-секрет, норматив «branch protection НЕ включать» (ADR D10 ORCH-009) (AC-1/AC-7/FR-1.6/§3.8 А-1) | `test_gitea_section_fixes_platform_invariants`, `test_gitea_section_forbids_branch_protection` | PASS |
-| TC-08 | Перекрёстная документация: REPLICATION §1 ссылается на LITE_SETUP; CHANGELOG несёт ORCH-102 (AC-5/FR-7) | `test_replication_boundaries_reference_lite_setup`, `test_changelog_has_orch_102_entry` | PASS |
-| TC-09 | Приёмочный smoke-прогон по LITE_SETUP на чистом контуре; вердикт фиксируется tester'ом (процедура, не pytest) (AC-4/FR-5) | см. раздел «Smoke-процедура Lite-тиража» + «Smoke API» выше | PASS |
-| TC-10 | Полный регресс `pytest tests/ -q` зелёный; существующие структурные тесты не ослаблены; дифф не трогает машину стадий/QG/вердикты/схему БД (AC-5/AC-7/NFR-2) | весь набор — **1789 passed** | PASS |
-
-Соответствие критериям `03-acceptance-criteria.md`: AC-1 (TC-01/02/03), AC-2 (TC-04), AC-3 (TC-05),
-AC-4 (TC-09 + smoke-процедура), AC-5 (TC-08/TC-10), AC-6 (TC-03/06), AC-7 (TC-07/TC-10) — все
-покрыты и зелёные.
-
-## Вывод pytest
-```
-============================= test session starts ==============================
-platform linux -- Python 3.12.13, pytest-8.3.3, pluggy-1.6.0
-rootdir: /repos/_wt/orchestrator/feature_ORCH-102-orch-10a-lite-watchdog
-configfile: pytest.ini
-plugins: cov-5.0.0, anyio-4.13.0, asyncio-0.23.8
-........................................................................ [100%]
-================== 1789 passed, 1 warning in 64.06s (0:01:04) ==================
-```
-(единственный warning — PydanticDeprecatedSince20 в `src/config.py:8`, предсуществующий, не связан с задачей.)
-
-Целевой модуль задачи (отдельный прогон):
-```
-tests/test_lite_setup_doc.py
-======================== 25 passed, 1 warning in 0.44s =========================
-```
-(25 структурных тестов покрывают TC-01…TC-08; заявление CHANGELOG «25 структурных тестов» совпадает с фактом.)
-
-## Итог
-**PASS** — полный регресс зелёный (1789 passed), все 10 TC из `04-test-plan.yaml` выполнены и
-сопоставлены с критериями `03-acceptance-criteria.md`. Smoke API read-only (включая блоки
-`serial_gate` и `auto_labels` в `/queue`, `/metrics schema_version:1`) и smoke-процедура
-Lite-тиража (LITE_SETUP.md + безопасный прогон `gen_secrets.py`, stateless, без переноса данных)
-зелёные. Задача переходит на `deploy-staging`.
-</content>
-</invoke>

docs/work-items/ORCH-102/14-deploy-log.md

@@ -1,12 +0,0 @@
----
-deploy_status: SUCCESS
-work_item: ORCH-102
-hook_exit_code: 0
-deployed_by: deploy-finalizer
----
-
-# Deploy log — ORCH-036 executable self-deploy
-
-Прод-деплой завершён хост-хуком с exit-code `0` -> `deploy_status: SUCCESS`.
-
-Вердикт зафиксирован детерминированным finalizer'ом (Фаза C), не LLM.

docs/work-items/ORCH-102/15-staging-log.md

@@ -1,36 +0,0 @@
----
-staging_status: SUCCESS
-work_item: ORCH-102
-stage: deploy-staging
-author_agent: deployer
-status: success
-created_at: 2026-06-11
-model_used: claude-opus-4-8
-timestamp: 2026-06-10T21:39:20Z
-base_url: http://localhost:8501
----
-
-# Staging Gate Log
-
-Staging test suite completed. Canonical run **inside** the `orchestrator-staging` container
-(8501) via the Docker exec API (`scripts/staging_check.py --base-url http://localhost:8501
---mode stub`). Exit code **0** → `staging_status: SUCCESS`.
-
-All REAL checks green. The only two failures are the known sandbox-infra checks C9a/C9b
-(depend on SANDBOX bot accounts being project members, not on the pipeline) and are
-waived under ORCH-061 tolerance (`staging_infra_tolerance_enabled=True`).
-
-```
-INFRA-WAIVED: C9a Branch appears in orchestrator-sandbox, C9b Analyst job enqueued in staging queue (known sandbox-infra; real checks green)
-VERDICT: SUCCESS (exit 0) — SUCCESS (infra-waived): ['C9a Branch appears in orchestrator-sandbox', 'C9b Analyst job enqueued in staging queue'] are known sandbox-infra checks; all real checks green
-```
-
-## Results
-- **Block A (SMOKE)**: PASS — A1 `/health` 200 ok, A2 `/queue` 200 with counts/max_concurrency/resilience, A3 `ORCH_STAGING=true`.
-- **Block B (ACCESS)**: PASS — B4 Plane sandbox accessible, B5 Gitea `orchestrator-sandbox` push=true, B6 registry isolation (sandbox present, prod ET/ORCH absent).
-- **Block C (E2E, mode=stub)**: C7 create issue PASS, C8 trigger pipeline PASS; C9a/C9b FAIL → **waived** (sandbox-infra, ORCH-061).
-
-RESULT: 8/10 checks PASS. REAL failed: none. SANDBOX_INFRA failed (waived): C9a, C9b.
-
-> Note: ORCH-102 is a docs+tests-only change (`src/**`/compose/Dockerfile/`scripts/**` untouched);
-> the staging gate is run as the mandatory self-hosting safety net before prod deploy.

docs/work-items/ORCH-103/00-business-request.md

@@ -1,7 +0,0 @@
-# Business Request: ORCH-10b Bundled-тираж: весь стек одним комплектом + bootstrap-скрипт
-
-Work Item ID: ORCH-103
-
-## Description
-
-TBD

docs/work-items/ORCH-103/01-brd.md

@@ -1,199 +0,0 @@
----
-work_item: ORCH-103
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-11
-model_used: claude-opus-4-8
----
-
-# 01 — BRD: ORCH-103 — ORCH-10b Bundled-тираж: весь стек одним комплектом + bootstrap-скрипт
-
-Work Item: **ORCH-103** · Repo: **orchestrator** (self-hosting) · Стадия: analysis
-Заказчик: Слава · Эпик: **ORCH-10** (домен D5 «Масштаб», `docs/epics/self-evolution.md`) · Тип: **B — Bundled**
-
----
-
-## 1. Бизнес-контекст и проблема
-
-### 1.1. Цель эпика ORCH-10
-Тираж платформы — РАЗДАЧА текущей функциональности нескольким заказчикам **на тест**.
-Решения Владельца 10.06 (приняты как требования): ДВА типа тиража, ОБА **stateless**
-(наши задачи/данные/секреты НЕ переносим — чистый старт):
-
-- **Тип A (Lite, ORCH-102 ✅)** — переносится ТОЛЬКО орк+watchdog; Plane/Gitea/LLM/Telegram
-  заказчик донастраивает сам по инструкции `docs/deployment/LITE_SETUP.md`.
-- **Тип B (Bundled, эта задача)** — **весь стек одним комплектом**
-  (орк + watchdog + Gitea + Plane + рантайм-обвязка агентов) — «под ключ».
-
-### 1.2. Проблема, которую закрывает ORCH-103
-Lite предполагает, что у заказчика **уже есть** (или он сам поднимет) свои Plane и Gitea.
-Для заказчика без собственной инфраструктуры это барьер: Plane CE self-hosted — это ~14
-контейнеров со своей БД/брокером/хранилищем, Gitea — отдельная установка, и поверх всего —
-первичная инициализация (админы, токены, workspace, 22 статуса, лейблы, вебхуки в обе стороны,
-git-доступ агентов). Сегодня репо не содержит ни compose-описания этого стека, ни автоматизации
-его доводки: разворачивание «с нуля до работающего конвейера» = многочасовая ручная работа по
-сторонним докам с рисками дефолтных паролей и дрейфа от канона платформы.
-
-ORCH-103 должен дать: **один compose-комплект** всего стека + **bootstrap-скрипт**, доводящий
-свежеподнятый стек до рабочего состояния одной командой/визардом, + **новые секреты** на каждую
-инсталляцию + **инструкцию `docs/deployment/BUNDLED_SETUP.md`** с требованиями к хосту.
-
-### 1.3. Установленные факты (проверено по репо — не изобретать)
-- **Корневой `docker-compose.yml` защищён анти-дрейфом:** ровно 3 сервиса
-  (`orchestrator`, `orchestrator-watchdog`, `orchestrator-staging` за `profiles: ["staging"]`);
-  `tests/test_lite_setup_doc.py` (TC-04) проверяет точное множество сервисов и **запрещает**
-  появление в нём имён/образов с подстроками `plane`/`gitea` → bundle-компоуз обязан быть
-  **отдельным файлом**, корневой compose не форкается и не расширяется.
-- **Кирпичи уже в `main` (переиспользовать, не дублировать):**
-  - `scripts/gen_secrets.py` (ORCH-101) — криптослучайные webhook-секреты
-    (`ORCH_PLANE_WEBHOOK_SECRET`/`ORCH_GITEA_WEBHOOK_SECRET`), печать по умолчанию,
-    `--write` отказывает при существующем `.env`, `--force` — перезапись; exit 0/2.
-  - `scripts/onboard_project.py` (ORCH-009) — `plan` (GET-only) / `apply` (идемпотентный ensure,
-    без delete) / `verify`: Plane-проект + **22 статуса** (read-only импорт
-    `plane_sync._PLANE_NAME_TO_KEY`, fail-closed имена `Confirm Deploy`/`STOP`) + лейблы
-    `autoApprove`/`autoDeploy`/`Bug`; Gitea-репо + per-repo webhook (`push`/`pull_request`/`status`,
-    ОДИН глобальный `ORCH_GITEA_WEBHOOK_SECRET`); недоступное в Plane CE API → `manual-step`
-    (fail-safe); exit 0/2/1.
-  - `docs/operations/REPLICATION.md` (ORCH-101) — карта env (§2), чек-лист секретов (§3),
-    **smoke §4** (шаги 0–6 с PASS/FAIL: config-резолв → `/health` → `/queue`+`/metrics` →
-    onboard plan/apply/verify → тестовая задача → артефакты `01–04` → опц. до `done`); §1 —
-    таблица границ, где Type B помечен «отдельная задача».
-  - `docs/deployment/LITE_SETUP.md` (ORCH-102) — канон тиражной инструкции: 13 нормативных
-    разделов, каждый шаг = fenced-команда + явная «Проверка:» PASS/FAIL, хост-специфика только
-    плейсхолдерами; канон не форкается — общие шаги ссылками.
-  - `.env.example` — канон 100% ключей орка; `.env.watchdog.example` — канон watchdog
-    (key-set-sync тестом, D5 ORCH-102).
-- **Хост-параметризация завершена (ORCH-101):** платформа разворачивается без правки кода —
-  только env (`${VAR:-default}`-интерполяция compose, `ARG APP_*` Dockerfile); анти-регресс
-  `tests/test_no_host_hardcodes.py` (FORBIDDEN-литералы: IP/`/home/slin`/`mva154`/`duckdns`).
-- **Claude CLI НЕ запечён в образ орка:** монтируется с хоста
-  (`ORCH_HOST_CLAUDE_CODE_DIR`/`ORCH_HOST_NODE_BIN`/`ORCH_HOST_CLAUDE_DIR`/`ORCH_HOST_CLAUDE_JSON`).
-  «Агенты» в комплекте = рантайм-обвязка запуска; **инсталляция Claude CLI и LLM-ключ — внешнее
-  предусловие хоста заказчика** (как Lite §7), bundle их не содержит и не генерирует.
-- **Нормативы тиражной Gitea:** branch protection на `main` НЕ включать (D10 ORCH-009 / INV-4 —
-  мерж только через Gitea PR-merge API); pre-receive не вводится.
-- **Plane CE self-hosted ≈ 14 контейнеров** (web/admin/space/api/worker/beat/live/migrator +
-  postgres/redis/mq/minio/proxy) — ресурсоёмко; часть первичной инициализации в CE недоступна
-  по API → честные ручные чекпоинты (паттерн `manual-step` ORCH-009).
-
----
-
-## 2. Объём (scope)
-
-### 2.1. В объёме
-- **Bundle-compose** — отдельный compose-комплект всего стека: орк + watchdog + Gitea +
-  Plane-стек (~14 контейнеров); пиннинг версий; чистые именованные тома; согласованная
-  сетевая достижимость (вебхуки в обе стороны).
-- **Bootstrap-скрипт** — один запуск (команда/визард): поднять всё → дождаться
-  готовности/миграций → инициализация Gitea (админ/токен) → инициализация Plane
-  (instance/workspace/API-токен; CE-ограничения → явные manual-step чекпоинты) →
-  онбординг sandbox-проекта (22 статуса/3 лейбла/репо/вебхуки — через `onboard_project.py`) →
-  git-доступ агентов → сборка `.env`/`.env.watchdog` орка → health → smoke-подсказка.
-- **Инициализация секретов** — генерация НОВЫХ на каждую инсталляцию (reuse `gen_secrets.py` +
-  bundle-внутренние креды: пароли БД/брокера/хранилища Plane, админ Gitea); дефолтных паролей
-  в репо нет.
-- **`docs/deployment/BUNDLED_SETUP.md`** — инструкция запуска bundle по канону LITE_SETUP,
-  включая **требования к хосту (RAM/диск/CPU/порты)**.
-- **Структурные анти-дрейф тесты** (без docker/сети/LLM в CI) + полный зелёный pytest + CHANGELOG.
-- Отметка Type B в `docs/operations/REPLICATION.md` §1 (границы трёх задач эпика).
-
-### 2.2. Вне объёма (явно, не делать)
-- Изменения рантайма: `src/**`, корневой `docker-compose.yml`, `Dockerfile`, `.gitea/workflows/`,
-  `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схема БД — байт-в-байт.
-- Перенос наших задач/данных/секретов (stateless — решение Владельца 10.06).
-- Автоматическая установка Claude CLI / выдача LLM-ключей / создание Telegram-ботов —
-  внешние предусловия заказчика (документируются, не автоматизируются).
-- HTTPS/домены/публичный reverse-proxy заказчика — за рамками bundle (документируется
-  как ручной шаг при необходимости).
-- Процедура обновления (upgrade) развёрнутого bundle; миграция Lite→Bundled; кластерные/
-  multi-host топологии; мультитенантность (D5.6) и горизонтальный воркер-пул (D5.4).
-- Какая-либо активация bundle на НАШЕМ боевом хосте.
-
----
-
-## 3. Заинтересованные стороны
-- **Владелец (Слава)** — раздаёт платформу заказчикам на тест; принимает результат.
-- **Оператор заказчика** — целевой читатель BUNDLED_SETUP.md: чистый Linux-хост,
-  docker+compose, без знания внутренностей платформы.
-- **Self-hosting прод** (`orchestrator`, общий для всех проектов) — не должен быть затронут:
-  задача — артефакты репо (compose/скрипт/доки/тесты), активируемые только явным запуском
-  на ЦЕЛЕВОМ хосте.
-
----
-
-## 4. Бизнес-требования (BR)
-
-| ID | Требование | Связь |
-|----|------------|-------|
-| BR-1 | Единый bundle-compose (отдельный файл) поднимает ВЕСЬ стек одной командой: орк, watchdog, Gitea, Plane-стек. Корневой `docker-compose.yml` не форкается и не меняется. | AC-1, AC-6, FR-1 |
-| BR-2 | Bootstrap-скрипт ОДНИМ запуском (команда/визард) доводит свежеподнятый стек до рабочего состояния: готовность/миграции → init Gitea → init Plane → онбординг sandbox-проекта → git-доступ агентов → конфиг орка → health. Шаги, физически недоступные через Plane CE API, оформляются явными интерактивными manual-step чекпоинтами (fail-safe, паттерн ORCH-009) — без молчаливых пропусков. | AC-1, FR-2 |
-| BR-3 | После bootstrap smoke проходит: тестовый проект создан, тестовая задача доезжает минимум до артефактов `01–04` в ветке (минимальный сигнал REPLICATION §4 шаг 5); расширенно — до `done`. Вебхуки работают в ОБЕ стороны (Plane→орк, Gitea→орк, орк→Plane/Gitea API). | AC-2, FR-2/FR-6 |
-| BR-4 | Stateless: каждая инсталляция стартует с чистых томов/БД (Plane, Gitea, орк) и НОВЫХ секретов (`gen_secrets.py` + bundle-внутренние креды). Боевые данные/секреты не используются ни на одном шаге; в репо нет ни одного реального секрета/дефолтного пароля. | AC-3, FR-3 |
-| BR-5 | `docs/deployment/BUNDLED_SETUP.md` написан по канону LITE_SETUP (fenced-команды + «Проверка:» PASS/FAIL, плейсхолдеры вместо хост-специфики, канон не форкается — общие шаги ссылками на LITE_SETUP/ONBOARDING/REPLICATION) и фиксирует требования к хосту: RAM/диск/CPU/занимаемые порты (Plane ~14 контейнеров — ресурсоёмко). | AC-4, FR-4 |
-| BR-6 | Переиспользование кирпичей без дублирования: секреты — `gen_secrets.py`; статусы/лейблы/репо/вебхуки — `onboard_project.py` (22 статуса — из `plane_sync._PLANE_NAME_TO_KEY`, нулевой дрейф); smoke — шаги REPLICATION §4. Bootstrap не реализует собственную копию этих канонов. | FR-2/FR-3, AC-7 |
-| BR-7 | Идемпотентность/fail-safe: повторный запуск bootstrap безопасен (ensure/skip, без delete-операций); запуск на «грязном» хосте (существующие тома/занятые порты/нехватка ресурсов) → явный отказ preflight с понятной подсказкой, а не молчаливое переиспользование чужого состояния. | FR-2, AC-8 |
-| BR-8 | Наш прод не затрагивается: вся задача — вне рантайма и вне конвейера; kill-switch не требуется (активация — только явный запуск человеком на целевом хосте, паттерн ORCH-009). | NFR-1/NFR-2, AC-6 |
-| BR-9 | Анти-дрейф: структурные тесты держат bundle-канон (compose-структура, док-канон, env-ключи, FORBIDDEN-литералы, секрет-эвристика, кросс-ссылки); существующие `test_lite_setup_doc.py`/`test_no_host_hardcodes.py` остаются зелёными; полный `pytest tests/ -q` зелёный; CHANGELOG обновлён. | AC-5, AC-6, AC-7, FR-5 |
-
----
-
-## 5. Нефункциональные требования (NFR)
-
-| ID | Требование |
-|----|------------|
-| NFR-1 | **Рантайм/конвейер байт-в-байт:** `src/**`, корневой `docker-compose.yml`, `Dockerfile`, `STAGE_TRANSITIONS`, `QG_CHECKS`, `check_*`, machine-verdict ключи, схема БД орка — не тронуты. Задача — docs+scripts+compose-bundle+tests. |
-| NFR-2 | **Self-hosting безопасность:** ни один артефакт задачи не рестартит/не деплоит/не конфигурирует наш прод-контейнер; bundle-артефакты в нашем контуре инертны (никто их не исполняет). |
-| NFR-3 | **Секрет-гигиена:** в репо не попадают реальные секреты, высокоэнтропийные литералы и хост-литералы (FORBIDDEN-скан `test_no_host_hardcodes.py` распространяется на новые артефакты); bootstrap не печатает секреты в лог; сгенерированные файлы конфигов — только на целевом хосте, в `.gitignore`. |
-| NFR-4 | **Переносимость:** bundle не зависит от нашей инфраструктуры; вся хост-специфика — переменные/плейсхолдеры; целевая платформа — одиночный Linux x86_64 хост с docker+compose. |
-| NFR-5 | **Норматив сопровождения** (зеркало NFR-5 ORCH-102): изменение шагов тиража в будущих задачах → обновление `BUNDLED_SETUP.md` в том же PR. |
-| NFR-6 | **Воспроизводимость:** версии образов Gitea/Plane-стека зафиксированы (пиннинг тегов/digest, не `latest`); состав bundle детерминирован. |
-| NFR-7 | **Без новых тяжёлых зависимостей:** bootstrap — в духе существующих скриптов (stdlib-инструментарий `gen_secrets.py`/`onboard_project.py`); точный стек (bash/python) — решение архитектора. |
-
----
-
-## 6. Допущения и ограничения
-- Целевой хост: чистый одиночный Linux x86_64 с установленными docker + docker compose;
-  оператор имеет sudo. Прочие ОС — вне целевой платформы (best-effort).
-- Ресурсы: Plane-стек ресурсоёмок; ориентир для проверки — **не менее 4 vCPU / 8 GB RAM /
-  40 GB диска** (финальные минимумы УТОЧНЯЮТСЯ при реализации замером на тестовом
-  развёртывании и фиксируются в BUNDLED_SETUP.md — см. AC-4; цифры выше — гипотеза, не факт).
-- Внешние предусловия заказчика (bundle не поставляет): инсталляция/аутентификация Claude CLI
-  + LLM-доступ Anthropic; Telegram-боты (трекер + watchdog) — опциональны, их отсутствие
-  деградирует только нотификации (never-raise), не конвейер.
-- Часть инициализации Plane CE недоступна по API (instance-setup/workspace/API-токен) —
-  допускаются документированные интерактивные шаги внутри визарда; «одной командой» означает
-  «один запуск bootstrap с явными чекпоинтами», а не «ноль действий человека».
-- Версии upstream-образов (Plane CE/Gitea) фиксируются на момент реализации; их обновление —
-  отдельные будущие задачи (NFR-6).
-
----
-
-## 7. Критерии успеха (резюме; детали — 03-acceptance-criteria.md)
-Пять AC из постановки Владельца (сохранены 1:1 как AC-1…AC-5) + производные проверяемые:
-- AC-1 единый bundle-compose поднимает ВЕСЬ стек; bootstrap доводит до рабочего состояния
-  одной командой/визардом.
-- AC-2 после bootstrap smoke проходит (тестовый проект + задача доезжает).
-- AC-3 stateless (чистые Plane/Gitea/БД, новые секреты).
-- AC-4 BUNDLED_SETUP.md + требования к хосту (RAM/диск) задокументированы.
-- AC-5 pytest зелёный; CHANGELOG.
-- AC-6 корневой compose/рантайм не тронуты (анти-дрейф зелёный); AC-7 нулевой дрейф канонов
-  (22 статуса/лейблы/секреты — через существующие кирпичи); AC-8 идемпотентность/fail-safe
-  bootstrap; AC-9 секрет-гигиена новых артефактов.
-
----
-
-## 8. Риски (детали — 10-tech-risks.md, заполняет архитектор)
-- **R-1 Ресурсоёмкость Plane:** ~14 контейнеров → OOM/медленный старт на слабом хосте;
-  смягчение — preflight-проверка ресурсов + честные требования в доке (AC-4).
-- **R-2 Дыры Plane CE API:** первичная инициализация частично UI-only → ручные чекпоинты;
-  риск — UX «одной команды» размывается; смягчение — явные manual-step с проверкой результата
-  (паттерн ORCH-009), минимизация числа ручных шагов.
-- **R-3 Дрейф upstream-образов:** «плавающие» теги ломают воспроизводимость → пиннинг (NFR-6).
-- **R-4 Сетевая достижимость вебхуков:** орк (host network) ⟷ Plane/Gitea (bridge-сеть bundle)
-  — двунаправленные URL должны быть согласованы bootstrap'ом; ошибка = «задача не появилась»
-  (труднодиагностируемо); смягчение — smoke проверяет оба направления.
-- **R-5 Соблазн форкнуть корневой compose** (анти-дрейф TC-04 `test_lite_setup_doc.py` упадёт)
-  → bundle строго отдельным файлом.
-- **R-6 Утечка секретов в логи/репо** при генерации bundle-кред → секрет-эвристика в тестах,
-  запрет печати секретов (NFR-3).

docs/work-items/ORCH-103/02-trz.md

@@ -1,232 +0,0 @@
----
-work_item: ORCH-103
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-11
-model_used: claude-opus-4-8
----
-
-# 02 — ТЗ (TRZ): ORCH-103 — ORCH-10b Bundled-тираж: весь стек одним комплектом + bootstrap-скрипт
-
-Work Item: **ORCH-103** · Repo: **orchestrator** · Стадия: analysis
-
-> ТЗ фиксирует **что** должно измениться и **где** (артефакты/контракты/границы). **Как**
-> (расположение bundle-каталога, состав сервисов Plane-стека, язык/режимы bootstrap, механизм
-> сетевой связности) — решает архитектор в `06-adr/`. Архитектурные решения здесь не принимаются.
-
----
-
-## 1. Сводка изменения
-
-Добавить в репо **Bundled-комплект тиража (Type B эпика ORCH-10)**: (1) отдельный
-**bundle-compose** всего стека (орк + watchdog + Gitea + Plane-стек ~14 контейнеров),
-(2) **bootstrap-скрипт**, доводящий свежеподнятый стек до рабочего конвейера одним запуском
-(с явными manual-step чекпоинтами там, где Plane CE API не позволяет автоматизацию),
-(3) **генерацию новых секретов** на инсталляцию (reuse `gen_secrets.py` + bundle-внутренние
-креды), (4) инструкцию **`docs/deployment/BUNDLED_SETUP.md`** с требованиями к хосту,
-(5) **структурные анти-дрейф тесты**. Всё — вне рантайма и вне конвейера: `src/**`, корневой
-`docker-compose.yml`, `Dockerfile`, `STAGE_TRANSITIONS`/`QG_CHECKS`/схема БД — байт-в-байт
-(паттерн ORCH-009/ORCH-102). Kill-switch не требуется: активация — только явный запуск
-оператором на целевом хосте.
-
----
-
-## 2. Задействованные модули / пути
-
-| Путь | Действие | Назначение |
-|------|----------|------------|
-| `deploy/bundled/docker-compose.yml` *(рабочая гипотеза; финальное расположение/имя — ADR; далее «bundle-compose»)* | **создать** | Compose-комплект всего стека (FR-1) |
-| `deploy/bundled/.env.bundled.example` *(имя — ADR; далее «bundle-конфиг-канон»)* | **создать** | Канон 100% переменных bundle (порты/версии/плейсхолдеры кред), паттерн `.env.watchdog.example` |
-| `scripts/bootstrap_bundle.py` *(имя/язык — ADR)* | **создать** | Bootstrap-скрипт (FR-2) |
-| `docs/deployment/BUNDLED_SETUP.md` | **создать** | Golden source инструкции Bundled-тиража (FR-4) |
-| `docs/operations/REPLICATION.md` | **изменить (точечно)** | §1: строка Type B → ✅ ORCH-103 + ссылка на BUNDLED_SETUP.md (FR-6) |
-| `tests/test_bundle_compose.py` | **создать** | Структура bundle-compose + изоляция корневого compose (FR-5) |
-| `tests/test_bundled_setup_doc.py` | **создать** | Канон дока, env-ключи, FORBIDDEN/секрет-эвристика, кросс-рефы (FR-5) |
-| `tests/test_bootstrap_script.py` | **создать** | Структурные/unit-ассерты bootstrap (FR-5) |
-| `CHANGELOG.md` | **изменить** | Запись `feat: ORCH-103` |
-| `.gitignore` | **изменить (при необходимости)** | Сгенерированные на хосте конфиги bundle не коммитятся (NFR-3) |
-| **НЕ трогать:** `src/**`, корневой `docker-compose.yml`, `Dockerfile`, `.gitea/workflows/**`, `.env.example` (кроме явно обоснованного в ADR аддитива), `onboarding/**`, промпты `.openclaw/agents/**` | — | NFR-1; анти-дрейф `test_lite_setup_doc.py` (TC-04: ровно 3 сервиса, нет `plane*`/`gitea*`) и `test_no_host_hardcodes.py` остаются зелёными |
-
----
-
-## 3. Функциональные требования
-
-### FR-1 — Bundle-compose всего стека (BR-1)
-- **Отдельный файл**, корневой `docker-compose.yml` не изменяется (жёсткое ограничение:
-  анти-дрейф TC-04 `tests/test_lite_setup_doc.py` проверяет точное множество сервисов корневого
-  compose и запрещает подстроки `plane`/`gitea` в именах сервисов/образов/контейнеров).
-- **Состав стека:** `orchestrator` (образ собирается из существующего корневого `Dockerfile` —
-  без его правки), `orchestrator-watchdog` (существующий `watchdog/Dockerfile`), Gitea
-  (+ её хранилище), полный Plane CE-стек (~14 контейнеров: web/admin/space/api/worker/beat/
-  live/migrator + postgres/redis/mq/minio/proxy — точный состав и версии пиннит архитектор по
-  upstream-référence). Staging-контур орка (8501) — НЕ в дефолтном `up` (вне скоупа заказчика;
-  включать ли за профилем — ADR).
-- **Пиннинг версий** всех сторонних образов (тег или digest; не `latest`) — NFR-6.
-- **Тома:** только именованные/каталожные тома bundle (узнаваемый префикс); чистый первый старт;
-  пересечений с томами/путями нашего прод-контура нет.
-- **Сеть и достижимость (двунаправленно):** (a) Plane→орк и Gitea→орк webhooks доставляются;
-  (b) орк→Plane API и орк→Gitea API доступны; (c) git push/fetch агентов в Gitea работает.
-  Механизм (bridge-сеть + публикация портов, `extra_hosts: host-gateway`, host-network — что
-  выбрать) — ADR; ТЗ фиксирует только инвариант достижимости, проверяемый smoke (FR-6).
-- **Порты:** карта портов по умолчанию задокументирована (BUNDLED_SETUP «Требования к хосту»);
-  порты конфигурируемы через bundle-конфиг; конфликт порта → отказ preflight bootstrap (FR-2),
-  не молчаливый сбой. Дефолт порта орка — существующий 8500 (`ORCH_DEPLOY_PROD_TARGET_PORT`).
-- **Конфиг-канон:** все параметры bundle (порты/версии/пути/плейсхолдеры кред) — в
-  bundle-конфиг-каноне; key-set синхронизируется структурным тестом (паттерн key-sync
-  `.env.watchdog.example`, D5 ORCH-102). Ключи орка НЕ дублируются — `.env` орка собирается
-  bootstrap'ом из существующего канона `.env.example`.
-
-### FR-2 — Bootstrap-скрипт: один запуск до рабочего состояния (BR-2, BR-6, BR-7)
-Последовательность (нумерация — норматив поведения; механика шагов — ADR):
-1. **Preflight (fail-fast, до любых мутаций):** docker+compose присутствуют; свободные
-   RAM/диск ≥ задокументированных минимумов; целевые порты свободны; тома bundle отсутствуют
-   (чистый хост) — иначе явный отказ с подсказкой (BR-7); наличие Claude CLI/кред — warning
-   (не блокер: конвейер без LLM не поедет, но стек поднимется).
-2. **Секреты (FR-3):** генерация полного набора НОВЫХ секретов инсталляции.
-3. **Up:** подъём bundle-compose; ожидание готовности каждого сервиса (healthcheck/готовность
-   БД/завершение миграций Plane и Gitea) с таймаутами и внятной диагностикой.
-4. **Init Gitea:** административная учётка + API-токен (через официальные механизмы Gitea —
-   CLI/env/API; конкретика — ADR); branch protection НЕ настраивается (норматив D10 ORCH-009).
-5. **Init Plane:** instance-setup/workspace/API-токен. Всё, что недоступно в CE по API, —
-   **интерактивный manual-step чекпоинт**: скрипт печатает точную инструкцию (URL/что нажать/
-   что ввести), ждёт подтверждения, **проверяет результат** (например, валидность введённого
-   API-токена запросом) и только тогда продолжает (fail-safe; молчаливый пропуск запрещён).
-6. **Онбординг sandbox-проекта:** вызов `scripts/onboard_project.py apply` + `verify`
-   (22 статуса из `plane_sync._PLANE_NAME_TO_KEY`, лейблы `autoApprove`/`autoDeploy`/`Bug`,
-   Gitea-репо, per-repo webhook под глобальным секретом). Собственная реализация этих шагов
-   в bootstrap **запрещена** (BR-6, нулевой дрейф канона).
-7. **Git-доступ агентов:** обеспечить push/fetch созданного репо из контейнера орка
-   (ssh-ключ + регистрация в Gitea ИЛИ токен-remote — механизм ADR); клон репо в repos-каталог
-   орка (`ORCH_HOST_REPOS_DIR`).
-8. **Конфиг орка:** собрать `.env` (на базе `.env.example`: URL'ы Plane/Gitea bundle-инсталляции,
-   токены, webhook-секреты, `ORCH_PROJECTS_JSON` из вывода onboard) и `.env.watchdog`
-   (из `.env.watchdog.example`); файлы остаются только на целевом хосте.
-9. **Health + итог:** `GET /health`, `GET /queue`, `GET /metrics` зелёные; финальная сводка
-   PASS/FAIL по всем шагам + следующая команда оператора (smoke FR-6).
-
-Требования к скрипту:
-- **Идемпотентность:** повторный запуск на уже-инициализированном bundle безопасен
-  (ensure/skip-семантика, как `onboard_project.py apply`); никаких delete-операций.
-- **Exit-коды:** `0` — успех; `2` — остановка на manual-step/незавершённое предусловие;
-  `1` — ошибка (паттерн `onboard_project.py`).
-- **Логи без секретов** (NFR-3): значения кред не печатаются (только имена ключей/пути файлов).
-- **Никогда не адресует наш прод:** в скрипте нет боевых хостов/путей (FORBIDDEN-скан),
-  работает только с локальным docker целевого хоста.
-- Желателен режим `plan` (печать шагов без мутаций, паттерн ORCH-009) — финально ADR.
-
-### FR-3 — Инициализация секретов: новые на каждую инсталляцию (BR-4)
-- **Webhook-секреты орка** — строго через существующий `scripts/gen_secrets.py`
-  (не реализовывать заново).
-- **Bundle-внутренние креды** (генерирует bootstrap, криптослучайно, stdlib `secrets`):
-  пароли postgres/redis*/mq/minio Plane-стека, секрет-ключи Plane, админ-пароль и API-токен
-  Gitea. В репо — только плейсхолдеры в bundle-конфиг-каноне; **ни одного дефолтного пароля**.
-- **Внешние секреты заказчика** (не генерятся, чек-лист в доке): Anthropic/Claude CLI доступ,
-  Telegram-токены (опционально), `ORCH_PLANE_API_TOKEN` (если выдаётся вручную на manual-step).
-- Сгенерированные файлы: только на целевом хосте, права `600`, в `.gitignore`; повторный
-  запуск НЕ перетирает существующие секреты без явного флага (паттерн `--force` gen_secrets).
-
-### FR-4 — `docs/deployment/BUNDLED_SETUP.md` (BR-5)
-- **Канон LITE_SETUP** (ORCH-102): нормативные разделы в порядке маршрута оператора; каждый
-  исполняемый шаг = fenced-команда + явная «Проверка:» с PASS/FAIL; хост-специфика — только
-  плейсхолдеры; запрещены FORBIDDEN-литералы и реальные секреты (структурный тест).
-- **Обязательные разделы** (минимум; точные заголовки — автор дока, проверяемость — тест):
-  (1) рамка Bundled (что входит/что НЕ входит: Claude CLI, Telegram, HTTPS; границы vs Lite);
-  (2) **требования к хосту** — RAM/диск/CPU/порты, явно «Plane ≈ 14 контейнеров», финальные
-  цифры — по замеру на тестовом развёртывании; (3) предусловия (docker/compose/sudo);
-  (4) получение кода; (5) секреты; (6) запуск bundle-compose; (7) bootstrap (включая перечень
-  manual-step чекпоинтов Plane); (8) LLM/Claude CLI (ссылкой на канон LITE_SETUP §7);
-  (9) Telegram (ссылкой на LITE_SETUP §8); (10) онбординг следующих проектов
-  (ссылкой на ONBOARDING.md); (11) smoke (шаги REPLICATION §4); (12) stateless-проверка;
-  (13) остановка/полный сброс инсталляции; (14) траблшутинг (минимум: webhook не доходит,
-  не хватает RAM/OOM, порт занят, claude не найден, Plane-миграции не завершились).
-- **Канон не форкается:** общие с Lite шаги — ссылками (LITE_SETUP §5–§8, ONBOARDING §1,
-  REPLICATION §2–§4), не копипастой; fail-closed имена `Confirm Deploy`/`STOP` и «22 статуса» —
-  согласованы с `plane_sync._PLANE_NAME_TO_KEY` (число — сверкой импорта в тесте, не литералом).
-
-### FR-5 — Структурные анти-дрейф тесты (BR-9)
-Все тесты — без docker/сети/LLM/subprocess-мутаций (CI-безопасные; паттерн
-`test_lite_setup_doc.py`):
-- **bundle-compose:** файл существует, валидный YAML; обязательные сервисы присутствуют
-  (`orchestrator`, `orchestrator-watchdog`, Gitea, Plane-стек — по списку из ADR); все
-  сторонние образы пиннованы (нет `:latest`/безтегового образа); корневой
-  `docker-compose.yml` НЕ изменён (множество сервисов == текущему эталону);
-- **док:** BUNDLED_SETUP.md существует, несёт обязательные разделы (включая «Требования к
-  хосту»), каждый env-ключ из дока существует в канонах (`.env.example` ∪ bundle-конфиг-канон),
-  кросс-ссылки на LITE_SETUP/ONBOARDING/REPLICATION присутствуют;
-- **гигиена:** FORBIDDEN-литералы (импорт списка из `test_no_host_hardcodes.py`) отсутствуют
-  в bundle-compose/доке/bootstrap; секрет-эвристика (hex ≥32 / alnum ≥40, паттерн D8 ORCH-102)
-  по новым файлам;
-- **bootstrap:** скрипт существует; структурно ссылается на `gen_secrets`/`onboard_project`
-  (не дублирует канон); не содержит delete-операций уровня `docker volume rm`/`rm -rf` вне
-  явного отдельного «сброс»-режима; чистые функции (preflight-решение, сборка плана шагов,
-  рендер `.env`) покрыты unit-тестами;
-- **кросс-рефы:** REPLICATION.md §1 несёт отметку Type B → BUNDLED_SETUP.md; CHANGELOG
-  содержит `ORCH-103`.
-
-### FR-6 — Smoke и наблюдаемость результата (BR-3)
-- Smoke Bundled = шаги REPLICATION §4 (0–6) поверх bundle-инсталляции, зафиксированные в
-  BUNDLED_SETUP §smoke: config-резолв → `/health` → `/queue`+`/metrics` → onboard verify →
-  тестовая задача (Plane issue → «To Analyse» → job в очереди) → **минимальный сигнал:
-  артефакты `01–04` в ветке** → опционально полный цикл до `done`.
-- Прохождение фиксируется оператором по PASS/FAIL каждого шага; это ручная приёмка AC-2
-  (e2e в CI не гоняется — нет docker/LLM).
-
----
-
-## 4. Изменения API
-**Нет.** Эндпоинты орка не добавляются/не меняются; bundle использует существующие
-`/health`, `/queue`, `/metrics`, вебхуки `/webhook/plane`, `/webhook/gitea`.
-
-## 5. Изменения схемы БД
-**Нет** (схема БД орка не тронута). БД Plane/Gitea внутри bundle — их собственные, на чистых
-томах инсталляции; к схеме орка отношения не имеют.
-
-## 6. Требования к новым/изменённым QG checks
-**Нет.** Реестр `QG_CHECKS`/`check_*`/`STAGE_TRANSITIONS` — байт-в-байт. Bundled-тираж — это
-артефакты дистрибуции, а не гейты конвейера.
-
----
-
-## 7. Совместимость / регресс
-- **Kill-switch не требуется** (паттерн ORCH-009): артефакты вне рантайма; в нашем контуре
-  ничего их не исполняет; активация — явный запуск оператором на целевом хосте.
-- **Нулевая регрессия:** корневой compose/`Dockerfile`/`src/**` не изменены ⇒ наш прод,
-  staging-контур и enduro-trails не затронуты по построению; существующие анти-дрейф тесты
-  (`test_lite_setup_doc.py`, `test_no_host_hardcodes.py`, канон-тесты ORCH-009) остаются
-  зелёными без правки их ассертов.
-- **Обратимость:** удаление bundle-каталога/скрипта/дока возвращает репо в текущее состояние;
-  на целевом хосте полный сброс = задокументированная процедура (FR-4 §13).
-- **Эскалация:** если при реализации выяснится необходимость править `src/**`/корневой compose
-  (например, недостающая параметризация, не закрытая ORCH-101) — это выход за рамки ТЗ:
-  остановиться и вернуть задачу с обоснованием (CLAUDE.md правило 4), не «дотачивать молча».
-
----
-
-## 8. Артефакты pipeline (создать/обновить в ТОМ ЖЕ PR)
-- `docs/work-items/ORCH-103/06-adr/ADR-001-<slug>.md` — решения архитектора (см. §9 OQ);
-  при сквозном значении — зеркало в `docs/architecture/adr/adr-NNNN-<slug>.md`.
-- `docs/architecture/README.md` — раздел «Bundled-тираж (ORCH-103)» рядом с 10-common/Lite.
-- `CLAUDE.md` — краткий абзац Type B (паттерн абзацев ORCH-101/102).
-- `docs/operations/REPLICATION.md` §1 — отметка Type B (FR-6).
-- `CHANGELOG.md` — `feat: ORCH-103 …`.
-- При выявлении инфра-предусловий целевого хоста — `07-infra-requirements.md` (архитектор).
-
----
-
-## 9. Открытые вопросы для архитектора (не блокируют анализ)
-- **OQ-1** Расположение/имя bundle-каталога и compose-файла (`deploy/bundled/` vs `bundle/`;
-  один compose vs include-композиция); судьба staging-контура орка в bundle (исключить vs
-  профиль).
-- **OQ-2** Точный состав/версии Plane CE-стека (по upstream selfhost-référence) и Gitea;
-  стратегия пиннинга (тег vs digest).
-- **OQ-3** Перечень физически автоматизируемых шагов инициализации Plane CE (instance-setup/
-  workspace/API-токен): что через API/CLI/seed, что — manual-step чекпоинт.
-- **OQ-4** Язык и режимы bootstrap (python stdlib vs bash; `plan`/`apply` vs линейный визард);
-  способ ожидания готовности (healthchecks vs poll).
-- **OQ-5** Механизм сетевой связности орк (host network?) ⟷ bundle bridge-сеть: публикация
-  портов, `host-gateway`, либо весь bundle в host-network — и согласование URL вебхуков.
-- **OQ-6** Механизм git-доступа агентов к bundle-Gitea (ssh-ключ vs http-токен) и наполнение
-  repos-каталога.
-- **OQ-7** Делать ли отдельный явный «сброс»-режим (teardown) частью скрипта или только
-  документированной процедурой в BUNDLED_SETUP §13.

docs/work-items/ORCH-103/03-acceptance-criteria.md

@@ -1,164 +0,0 @@
----
-work_item: ORCH-103
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-11
-model_used: claude-opus-4-8
----
-
-# 03 — Критерии приёмки (Acceptance Criteria): ORCH-103 — Bundled-тираж: весь стек одним комплектом + bootstrap-скрипт
-
-Work Item: **ORCH-103** · Repo: **orchestrator** · Стадия: analysis
-
-Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL**
-(что считается провалом). AC-1…AC-5 — из постановки Владельца (сохранены 1:1 по смыслу);
-AC-6…AC-9 — производные обязательные. AC-1/AC-2/AC-3 в части e2e — **ручная приёмка** на
-чистом тестовом хосте/VM по BUNDLED_SETUP.md (в CI docker/LLM не гоняются); остальное
-проверяется по файлам репозитория и структурным тестам.
-
----
-
-## AC-1 — Единый bundle поднимает ВЕСЬ стек; bootstrap доводит одной командой/визардом
-
-**Условие:** на чистом Linux-хосте с docker+compose по шагам BUNDLED_SETUP.md: одна команда
-`docker compose -f <bundle-compose> … up -d` поднимает все сервисы стека (орк + watchdog +
-Gitea + Plane-стек); затем ОДИН запуск bootstrap-скрипта доводит инсталляцию до рабочего
-состояния (init Gitea/Plane → онбординг sandbox-проекта → git-доступ агентов → конфиг орка →
-health). Интерактивные manual-step чекпоинты допустимы только там, где Plane CE API не
-позволяет автоматизацию, каждый — с инструкцией и проверкой результата.
-- **PASS:** все контейнеры bundle в состоянии Up/healthy; bootstrap завершается `exit 0`;
-  `GET /health` орка — 200/ok, `GET /queue` и `GET /metrics` отдают валидный JSON;
-  `onboard_project.py verify` зелёный (22 статуса, лейблы, репо, webhook); ни одного
-  НЕдокументированного ручного действия (правка compose/конфигов руками сверх инструкции).
-- **FAIL:** хотя бы один сервис не поднялся/в рестарт-цикле; bootstrap падает или завершается
-  с нерабочим конвейером; для доводки потребовались действия, отсутствующие в BUNDLED_SETUP.md;
-  manual-step пропускается молча без проверки результата.
-
----
-
-## AC-2 — После bootstrap smoke проходит (тестовый проект + задача доезжает)
-
-**Условие:** smoke-процедура BUNDLED_SETUP §smoke (шаги REPLICATION.md §4 поверх
-bundle-инсталляции): создать issue в sandbox-проекте Plane → перевести в «To Analyse».
-- **PASS:** webhook доезжает (job появляется в `GET /queue`); конвейер запускает analyst;
-  в рабочей ветке Gitea появляются артефакты `01-brd.md`/`02-trz.md`/`03-acceptance-criteria.md`/
-  `04-test-plan.yaml` (минимальный сигнал — шаг 5 REPLICATION §4); обратное направление
-  работает (орк пишет статус/коммент в Plane). Опционально-расширенно: задача доводится до
-  `done` (шаг 6).
-- **FAIL:** webhook не доходит (нет job); analyst не стартует; артефакты `01–04` не появляются;
-  орк не может писать в Plane/Gitea API (одностороння связность — R-4).
-
----
-
-## AC-3 — Stateless: чистые Plane/Gitea/БД, новые секреты
-
-**Условие:** инсталляция стартует с нуля и не содержит ничего нашего.
-- **PASS:** все тома bundle созданы заново при первом `up` (чистые БД Plane/Gitea/орка:
-  `GET /queue` — нулевые счётчики, в Plane/Gitea нет наших задач/репо/пользователей); ВСЕ
-  секреты инсталляции сгенерированы на месте (`gen_secrets.py` + bundle-креды bootstrap);
-  в репо нет ни одного реального секрета/дефолтного пароля (структурный тест: секрет-эвристика
-  + плейсхолдеры в bundle-конфиг-каноне); боевые данные/секреты/БД не копируются ни одним шагом
-  инструкции.
-- **FAIL:** инструкция/скрипт предлагает перенос наших данных или переиспользование боевых
-  секретов; в репо обнаружен реальный секрет/дефолтный пароль/высокоэнтропийный литерал;
-  на свежей инсталляции видны чужие задачи/счётчики.
-
----
-
-## AC-4 — BUNDLED_SETUP.md + требования к хосту задокументированы
-
-**Условие:** `docs/deployment/BUNDLED_SETUP.md` существует и написан по канону тиражных доков
-(ORCH-102).
-- **PASS:** док несёт обязательные разделы FR-4 (рамка, **требования к хосту с явными цифрами
-  RAM/диск/CPU и картой портов**, предусловия, секреты, запуск, bootstrap с перечнем
-  manual-step, LLM, Telegram, онбординг, smoke, stateless-проверка, остановка/сброс,
-  траблшутинг); каждый исполняемый шаг = fenced-команда + «Проверка:» PASS/FAIL; явно указано
-  «Plane ≈ 14 контейнеров — ресурсоёмко»; цифры требований подтверждены замером на тестовом
-  развёртывании (не «с потолка»); хост-специфика — только плейсхолдеры; общие шаги — ссылками
-  на LITE_SETUP/ONBOARDING/REPLICATION (без копипасты канона).
-- **FAIL:** дока нет/раздел «Требования к хосту» отсутствует или без цифр; шаги без
-  команд/проверок; FORBIDDEN-литералы (IP/`/home/slin`/`mva154`/`duckdns`) или секреты в
-  тексте/fenced-блоках; канон LITE_SETUP скопирован вместо ссылок.
-
----
-
-## AC-5 — pytest зелёный; CHANGELOG
-
-**Условие:** полный регресс и журнал изменений.
-- **PASS:** `pytest tests/ -q` — 0 failed (включая существующие анти-дрейф
-  `test_lite_setup_doc.py`, `test_no_host_hardcodes.py`, канон-тесты ORCH-009 — без правки их
-  ассертов); `CHANGELOG.md` содержит запись `ORCH-103`.
-- **FAIL:** хотя бы один тест красный; существующий анти-дрейф тест «починен» ослаблением
-  ассертов; CHANGELOG не обновлён.
-
----
-
-## AC-6 — Корневой compose и рантайм не тронуты
-
-**Условие:** изоляция от боевого контура (NFR-1/NFR-2, BR-1/BR-8).
-- **PASS:** `git diff main` НЕ содержит изменений `src/**`, корневого `docker-compose.yml`,
-  `Dockerfile`, `.gitea/workflows/**`; bundle-compose — отдельный файл; множество сервисов
-  корневого compose неизменно (`orchestrator`/`orchestrator-watchdog`/`orchestrator-staging`);
-  ни один артефакт задачи не исполняется в нашем контуре автоматически (нет правок
-  деплой-хука/CI, нет cron/врезок).
-- **FAIL:** любая правка рантайма/корневого compose/Dockerfile; сервисы `plane*`/`gitea*`
-  добавлены в корневой compose; артефакт bundle задействован в нашем прод/staging-контуре.
-
----
-
-## AC-7 — Нулевой дрейф канонов: кирпичи переиспользованы
-
-**Условие:** BR-6 — единственный источник истины для статусов/лейблов/секретов/smoke.
-- **PASS:** bootstrap вызывает `scripts/gen_secrets.py` (webhook-секреты) и
-  `scripts/onboard_project.py` (статусы/лейблы/репо/вебхуки) — структурный тест подтверждает
-  ссылки; собственного списка статусов/лейблов в bundle-артефактах нет (упоминание числа
-  статусов в доке сверяется импортом `plane_sync._PLANE_NAME_TO_KEY` в тесте, не литералом);
-  smoke-раздел ссылается на REPLICATION §4.
-- **FAIL:** bootstrap/док несут собственную копию канона (свой список статусов, свой генератор
-  webhook-секретов, свой smoke-чеклист с нуля) — дрейф при будущих изменениях канона.
-
----
-
-## AC-8 — Идемпотентность и fail-safe bootstrap
-
-**Условие:** BR-7 — повторный запуск и грязный хост.
-- **PASS:** повторный запуск bootstrap на уже-инициализированном bundle завершается успешно
-  (ensure/skip, без дублей и без разрушения состояния); preflight на грязном/непригодном хосте
-  (существующие тома bundle, занятый порт, нехватка RAM/диска) → явный отказ с понятной
-  подсказкой ДО любых мутаций; delete-операций нет (teardown — только отдельный
-  явный режим/процедура, не часть обычного прогона); exit-коды: 0 — успех, 2 — manual-step/
-  предусловие, 1 — ошибка; секреты в логи не печатаются; повторный запуск не перетирает
-  существующие секреты без явного флага.
-- **FAIL:** повторный запуск ломает/дублирует состояние; bootstrap молча переиспользует чужие
-  тома или продолжает после провального preflight; обычный прогон удаляет данные; секрет виден
-  в stdout/логе.
-
----
-
-## AC-9 — Секрет-гигиена и переносимость новых артефактов
-
-**Условие:** NFR-3/NFR-4/NFR-6 по файлам репо.
-- **PASS:** структурные тесты подтверждают: в bundle-compose/доке/скрипте нет
-  FORBIDDEN-литералов (список — импорт из `test_no_host_hardcodes.py`) и высокоэнтропийных
-  литералов (hex ≥32 / alnum ≥40); все сторонние образы bundle-compose пиннованы (не `latest`);
-  все env-ключи, упомянутые в BUNDLED_SETUP.md, существуют в канонах (`.env.example` ∪
-  bundle-конфиг-канон); сгенерированные на хосте конфиги — в `.gitignore`.
-- **FAIL:** найден хост-литерал/секрет; образ без пина; ключ-фантом в доке (нет в канонах);
-  сгенерированный конфиг коммитится.
-
----
-
-## Сводная матрица AC ↔ BR/FR
-
-| AC | Покрывает | Способ проверки |
-|----|-----------|-----------------|
-| AC-1 | BR-1, BR-2 / FR-1, FR-2 | ручной e2e на тестовом хосте + структурные тесты (TC-01..04, TC-08) |
-| AC-2 | BR-3 / FR-2, FR-6 | ручной e2e (smoke REPLICATION §4) |
-| AC-3 | BR-4 / FR-3 | ручной e2e + структурные тесты (TC-06, TC-09) |
-| AC-4 | BR-5 / FR-4 | структурный тест дока (TC-05) + ревью |
-| AC-5 | BR-9 / FR-5, FR-6 | `pytest tests/ -q` (TC-12) + CHANGELOG (TC-11) |
-| AC-6 | BR-1, BR-8 / NFR-1, NFR-2 | git diff + существующий анти-дрейф (TC-02) |
-| AC-7 | BR-6 / FR-2, FR-3 | структурный тест bootstrap/дока (TC-07, TC-10) |
-| AC-8 | BR-7 / FR-2 | unit-тесты чистых функций preflight/плана (TC-08) + ручной повторный прогон |
-| AC-9 | NFR-3, NFR-4, NFR-6 / FR-1, FR-4 | структурные тесты гигиены (TC-03, TC-06, TC-09) |

docs/work-items/ORCH-103/04-test-plan.yaml

@@ -1,102 +0,0 @@
-work_item: ORCH-103
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: 2026-06-11
-model_used: claude-opus-4-8
-title: "Bundled-тираж: bundle-compose + bootstrap + BUNDLED_SETUP.md (структурные анти-дрейф тесты)"
-framework: pytest
-scope: >
-  Автоматическое покрытие — СТРУКТУРНЫЕ инварианты артефактов Bundled-тиража
-  (bundle-compose, bootstrap-скрипт, docs/deployment/BUNDLED_SETUP.md) без docker/сети/LLM
-  в CI (паттерн tests/test_lite_setup_doc.py). Вне автоматического покрытия — фактический
-  e2e-подъём стека: он принимается ВРУЧНУЮ по чек-листу BUNDLED_SETUP §smoke
-  (шаги REPLICATION.md §4) на чистом тестовом хосте/VM — см. notes (AC-1/AC-2/AC-3/AC-8).
-notes: >
-  Ручная приёмка (вне CI): чистый Linux-хост/VM -> docker compose -f <bundle> up -d ->
-  один запуск bootstrap (manual-step чекпоинты Plane CE допустимы и проверяются) ->
-  health/queue/metrics зелёные -> onboard verify -> тестовая задача доезжает до артефактов
-  01-04 (минимальный сигнал), опционально до done; повторный запуск bootstrap безопасен;
-  тома чистые, секреты новые. Имена модулей tests/test_bundle_compose.py /
-  tests/test_bundled_setup_doc.py / tests/test_bootstrap_script.py — норматив тест-плана;
-  имена bundle-каталога/скрипта внутри ассертов следуют ADR-001 архитектора.
-  Полный регресс tests/ обязан остаться зелёным БЕЗ ослабления ассертов существующих
-  анти-дрейф тестов (test_lite_setup_doc.py, test_no_host_hardcodes.py, канон ORCH-009).
-
-tests:
-  # ---------- FR-1 / AC-1: bundle-compose ----------
-  - id: TC-01
-    type: unit
-    description: "Bundle-compose существует и валидно парсится (yaml.safe_load); содержит обязательные сервисы: orchestrator, orchestrator-watchdog, Gitea и Plane-стек (имена — по ADR-001); staging-контур орка не входит в дефолтный up"
-    module: tests/test_bundle_compose.py
-    expected: PASS
-
-  - id: TC-02
-    type: unit
-    description: "Корневой docker-compose.yml НЕ изменён: множество сервисов == {orchestrator, orchestrator-watchdog, orchestrator-staging}; в его сервисах/образах/container_name нет подстрок plane/gitea (зеркало TC-04 test_lite_setup_doc.py — существующий анти-дрейф остаётся зелёным)"
-    module: tests/test_bundle_compose.py
-    expected: PASS
-
-  - id: TC-03
-    type: unit
-    description: "Все сторонние образы bundle-compose пиннованы: ни одного image с тегом latest или без тега/digest (NFR-6, воспроизводимость)"
-    module: tests/test_bundle_compose.py
-    expected: PASS
-
-  - id: TC-04
-    type: unit
-    description: "Изоляция и конфиг-канон bundle: тома — именованные с узнаваемым bundle-префиксом, без bind-путей нашего прод-контура; bundle-конфиг-канон (example-файл) существует, и каждая ${VAR}-интерполяция bundle-compose имеет ключ в каноне (key-set-sync, паттерн .env.watchdog.example)"
-    module: tests/test_bundle_compose.py
-    expected: PASS
-
-  # ---------- FR-4 / AC-4: BUNDLED_SETUP.md ----------
-  - id: TC-05
-    type: unit
-    description: "docs/deployment/BUNDLED_SETUP.md существует и несёт обязательные разделы FR-4 (включая 'Требования к хосту' с цифрами RAM/диск/CPU, картой портов и упоминанием ~14 контейнеров Plane; bootstrap; smoke; stateless-проверка; остановка/сброс; траблшутинг); исполняемые шаги оформлены fenced-блоками с явной 'Проверка:'"
-    module: tests/test_bundled_setup_doc.py
-    expected: PASS
-
-  - id: TC-06
-    type: unit
-    description: "Гигиена новых артефактов (док + bundle-compose + bootstrap): нет FORBIDDEN-литералов (список — импорт из tests/test_no_host_hardcodes.py) и нет высокоэнтропийных секрет-литералов (hex >=32 / alnum >=40, эвристика D8 ORCH-102)"
-    module: tests/test_bundled_setup_doc.py
-    expected: PASS
-
-  # ---------- FR-2/FR-3 / AC-7: bootstrap переиспользует кирпичи ----------
-  - id: TC-07
-    type: unit
-    description: "Bootstrap-скрипт существует и структурно переиспользует канон: ссылается на scripts/gen_secrets.py и scripts/onboard_project.py; НЕ несёт собственного списка Plane-статусов/лейблов; в обычном прогоне нет delete-операций (docker volume rm / rm -rf допустимы только в отдельном явном reset-режиме, если введён ADR)"
-    module: tests/test_bootstrap_script.py
-    expected: PASS
-
-  - id: TC-08
-    type: unit
-    description: "Чистые функции bootstrap (preflight/план шагов): грязное состояние (существующие bundle-тома, занятый порт, нехватка RAM/диска) -> отказ с диагностикой ДО мутаций; чистое -> план полного прогона; контракт exit-кодов 0/2/1 (успех / manual-step-остановка / ошибка)"
-    module: tests/test_bootstrap_script.py
-    expected: PASS
-
-  # ---------- FR-4/FR-5 / AC-9: env-канон и нулевой дрейф ----------
-  - id: TC-09
-    type: unit
-    description: "Каждый env-ключ ORCH_*/WATCHDOG_*, упомянутый в BUNDLED_SETUP.md, существует в .env.example либо в bundle-конфиг-каноне (нет ключей-фантомов); упоминание ЧИСЛА статусов Plane сверяется импортом len(plane_sync._PLANE_NAME_TO_KEY), а не зашитым литералом"
-    module: tests/test_bundled_setup_doc.py
-    expected: PASS
-
-  - id: TC-10
-    type: unit
-    description: "Кросс-ссылки канона: BUNDLED_SETUP.md ссылается на LITE_SETUP.md, ONBOARDING.md и REPLICATION.md (канон не форкается); docs/operations/REPLICATION.md §1 несёт отметку Type B -> BUNDLED_SETUP.md / ORCH-103"
-    module: tests/test_bundled_setup_doc.py
-    expected: PASS
-
-  # ---------- AC-5: журнал и полный регресс ----------
-  - id: TC-11
-    type: unit
-    description: "CHANGELOG.md содержит запись ORCH-103"
-    module: tests/test_bundled_setup_doc.py
-    expected: PASS
-
-  - id: TC-12
-    type: integration
-    description: "Полный регресс pytest tests/ -q зелёный: новые тесты добавлены, существующие анти-дрейф (test_lite_setup_doc.py, test_no_host_hardcodes.py, канон-тесты ORCH-009) проходят БЕЗ изменения их ассертов"
-    module: tests/
-    expected: PASS

docs/work-items/ORCH-103/06-adr/ADR-001-bundled-stack-compose-and-bootstrap.md

@@ -1,362 +0,0 @@
----
-work_item: ORCH-103
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-11
-model_used: claude-opus-4-8
----
-
-# ADR-001: Bundled-тираж (Type B) — bundle-compose всего стека + bootstrap-канон
-
-Work Item: **ORCH-103** — ORCH-10b Bundled-тираж: весь стек одним комплектом + bootstrap-скрипт
-Стадия: **architecture**
-Сквозная регистрация: **`docs/architecture/adr/adr-0038-bundled-replication-canon.md`**
-(закрывает Type B эпика ORCH-10; вводит новый top-level каталог `deploy/` и нормативы,
-обязательные для будущих задач тиража).
-
-## Статус
-Proposed
-
-## Контекст
-
-Эпик ORCH-10 (D5 «Масштаб»), тип **B — Bundled**: заказчик без собственной инфраструктуры
-получает **весь стек одним комплектом** (орк + watchdog + Gitea + Plane CE) + bootstrap,
-доводящий стек до рабочего конвейера одним запуском. Факты, сверенные с репо:
-
-- **Корневой `docker-compose.yml` заморожен анти-дрейфом** (`tests/test_lite_setup_doc.py::
-  test_compose_services_are_exactly_the_lite_set` + `test_compose_has_no_plane_or_gitea_services`):
-  ровно 3 сервиса, подстроки `plane`/`gitea` запрещены → bundle обязан быть **отдельным файлом**.
-- **Кирпичи уже в `main`:** `scripts/gen_secrets.py` (webhook-секреты, `--write PATH`, exit 0/2),
-  `scripts/onboard_project.py` (`plan`/`apply`/`verify`, 22 статуса из
-  `plane_sync._PLANE_NAME_TO_KEY`, шаг `plane.workspace-webhook` — уже **MANUAL** в его отчёте,
-  token-push `_push_url`, exit 0/2/1; запуск — host-venv, `docs/operations/ONBOARDING.md`),
-  smoke `docs/operations/REPLICATION.md` §4, док-канон `docs/deployment/LITE_SETUP.md` (ORCH-102).
-- **Хост-параметризация закрыта ORCH-101** (adr-0036): `src/**` без хост-литералов
-  (`tests/test_no_host_hardcodes.py`, FORBIDDEN = `82.22.50.71`/`/home/slin`/`mva154`/`duckdns`);
-  internal/public split URL уже в конфиге (`ORCH_GITEA_URL`≠`ORCH_GITEA_PUBLIC_URL`,
-  `ORCH_PLANE_API_URL`≠`ORCH_PLANE_WEB_URL`).
-- **`.gitignore` уже неякорный** для `.env`, `data/`, `.env.watchdog` — вложенные копии этих имён
-  игнорируются на любом уровне без правок.
-- **Claude CLI не запекается** в образ (маунты `ORCH_HOST_CLAUDE_*`) — внешнее предусловие хоста
-  заказчика; bundle его не поставляет (решение Владельца, BRD §1.3).
-
-ТЗ (02-trz.md §9) оставило архитектору OQ-1…OQ-7. Ниже — пакет решений D1…D11.
-
-## Решение
-
-### Сводка
-
-Bundled-комплект живёт в новом top-level каталоге **`deploy/bundled/`**: самодостаточный
-compose-файл всего стека (зеркало официального Plane CE selfhost-référence + Gitea + орк +
-watchdog, пиннинг неподвижными тегами) на **одной bridge-сети** с сервис-DNS для машинного
-трафика и публикацией только «человеческих» портов. **`scripts/bootstrap_bundle.py`**
-(python stdlib, режимы `plan`/`apply`/`verify`, step-движок check→ensure, exit 0/2/1) доводит
-стек: preflight → секреты → up → init Gitea (полностью автоматом) → init Plane (честные
-manual-step с верификацией) → онбординг sandbox-проекта **строго** через `onboard_project.py` →
-git-доступ агентов token-remote → сборка `.env`/`.env.watchdog` орка → health/итог. Teardown —
-только документированная процедура. Рантайм байт-в-байт: `src/**`, корневой compose,
-`Dockerfile`, `STAGE_TRANSITIONS`/`QG_CHECKS`/machine-verdict/схема БД — не тронуты (NFR-1);
-kill-switch не нужен — активация только явным запуском оператора на целевом хосте
-(паттерн ORCH-009/102).
-
-### D1 — Расположение и изоляция: `deploy/bundled/`, project name `orchestrator-bundle` (OQ-1)
-
-- Новый top-level каталог **`deploy/`** — «дистрибутивы развёртывания» (исполняемые комплекты;
-  семантика дополняет `docs/deployment/` — инструкции). Bundle: **`deploy/bundled/docker-compose.yml`**,
-  один **самодостаточный** файл (include-композиция отвергнута — см. Альтернативы).
-- Top-level **`name: orchestrator-bundle`** в compose: project name фиксирован → все тома/контейнеры
-  получают узнаваемый префикс `orchestrator-bundle_*`/`orchestrator-bundle-*` (требование TC-04
-  тест-плана «узнаваемый bundle-префикс»; preflight bootstrap детектирует «грязный хост» по этому
-  префиксу). **`container_name` не пиннится ни у одного сервиса** — установка Lite и bundle на одном
-  хосте не сталкивается по именам с корневым compose (у которого `container_name: orchestrator`
-  закреплён).
-- **Staging-контур орка в bundle отсутствует вовсе** (ни сервисом, ни профилем): заказчик Type B
-  эксплуатирует платформу для СВОИХ проектов, а не развивает её self-hosting'ом; репо `orchestrator`
-  в bundle-инсталляции **не регистрируется** как проект → вся self-deploy-машинерия
-  (`SELF_HOSTING_REPO="orchestrator"`-леафы, freshness, serial-gate freeze) структурно спит.
-  Нужен self-hosting у заказчика → это маршрут Lite/корневого compose (LITE_SETUP §9), не bundle.
-- Имена сервисов: `orchestrator`, `orchestrator-watchdog` — платформенные конвенции (ORCH-101 D3);
-  `gitea`; Plane-стек — **upstream-имена** сервисов (минимальный дифф к référence, D3 ниже).
-  Запрет `plane*`/`gitea*` касается ТОЛЬКО корневого compose — на bundle-файл не распространяется.
-
-### D2 — Конфиг-слои: три файла, один писатель (OQ-1, FR-1/FR-3)
-
-| Файл | Роль | В гите |
-|------|------|--------|
-| `deploy/bundled/.env.example` | **bundle-конфиг-канон**: 100% ключей bundle-инфры (публичный хост, карта портов, uid/gid, пути Claude CLI, плейсхолдеры внутренних кред Plane/Gitea) | да (только плейсхолдеры/нейтральные дефолты) |
-| `deploy/bundled/.env` | live bundle-конфиг; **авто-читается compose** из project dir — все `docker compose -f deploy/bundled/docker-compose.yml …` работают без флагов | нет (покрыт неякорным `.env` в `.gitignore`) |
-| корневые `.env` / `.env.watchdog` | runtime-конфиг орка и watchdog — **ровно канон Lite** (REPLICATION §2 / `.env.example` / `.env.watchdog.example` применимы 1:1); в bundle-compose подключаются `env_file: ../../.env` (`required: false` — см. ниже) | нет (уже в `.gitignore`) |
-
-- **Отвергнут** отдельный live-файл с обязательным `--env-file`: оператор неизбежно наберёт голую
-  compose-команду без флага → интерполяции молча упадут в дефолты → пересоздание контейнеров с
-  чужими портами/путями (труднодиагностируемый класс R-4). Авто-`.env` в project dir — fail-safe
-  по построению.
-- **`env_file` орка/watchdog — `required: false`** (паттерн уже в корневом compose у watchdog):
-  первый `up -d` поднимает ВЕСЬ стек до того, как конфиг орка собран (AC-1 «одна команда»); орк
-  без конфига жив (`/health` отвечает), bootstrap пересоздаёт его после сборки env (шаг 8 D5).
-- **Bootstrap — единственный писатель** `deploy/bundled/.env` (дозапись сгенерённых кред),
-  корневого `.env` и `.env.watchdog` на целевом хосте: дублируемые между слоями ключи
-  (`ORCH_AGENT_HOME_DIR`, порт орка) когерентны механически, а не дисциплиной оператора.
-  Права `600`; повторный запуск НЕ перетирает существующие значения без явного флага
-  (паттерн `--force` `gen_secrets.py`).
-- **Неймспейсы ключей:** один факт = одно имя (ORCH-101 D1) — существующие факты переиспользуют
-  существующие имена (`ORCH_RUN_UID/GID`, `ORCH_DOCKER_GID`, `ORCH_AGENT_HOME_DIR`,
-  `ORCH_HOST_CLAUDE_CODE_DIR`/`ORCH_HOST_NODE_BIN`/`ORCH_HOST_CLAUDE_DIR`/`ORCH_HOST_CLAUDE_JSON`);
-  bundle-only факты — префикс **`BUNDLE_*`** (`BUNDLE_PUBLIC_HOST`, `BUNDLE_PLANE_PORT`,
-  `BUNDLE_GITEA_HTTP_PORT`, `BUNDLE_ORCH_PORT`); внутренние креды Plane-стека — **upstream-имена**
-  Plane CE (значения генерирует bootstrap). Точный состав финализирует developer; форму держит
-  key-set-sync тест: **каждая `${VAR}`-интерполяция bundle-compose имеет ключ в
-  `deploy/bundled/.env.example`** (паттерн `.env.watchdog.example`, D5 ORCH-102).
-- **Дефолты bundle-compose нейтральны** (FORBIDDEN-литералов нет — TC-06 распространяет скан на
-  bundle-артефакты): HOME акторов в bundle — `/home/orchestrator` (значение в `.env.example`
-  bundle, обе стороны группы ORCH-040 двигаются одной переменной — инвариант сохранён);
-  uid/gid/доки docker-gid заполняет bootstrap из `id -u`/`id -g`/`getent group docker`.
-- Каталоги данных орка — bind внутри project dir: `./data` → `deploy/bundled/data` (покрыт
-  неякорным `data/` в `.gitignore`), `./repos` → `deploy/bundled/repos` (**добавить в
-  `.gitignore`**: `deploy/bundled/repos/`); bind, а не named volume — те же uid-причины, что в
-  корневом compose (ORCH-040: named volume создаётся root-owned, контейнер бежит под uid
-  оператора). Состояние Plane/Gitea (postgres/redis/mq/minio/gitea-data) — **именованные тома**
-  проекта (root-владение для них нормально: процессы своих образов).
-
-### D3 — Состав стека и пиннинг: зеркало upstream, неподвижные теги литералом (OQ-2)
-
-- **Plane CE** — зеркало официального selfhost-compose Plane CE (web/space/admin/api/worker/
-  beat-worker/migrator/live + postgres/redis/mq/minio/proxy, ≈13–14 сервисов по факту référence
-  на момент пиннинга). Структура сервисов/env-контракт — upstream-имена (анти-дрейф к их докам;
-  своя «переписанная» топология Plane = неоплачиваемый долг сопровождения).
-- **Gitea** — официальный `gitea/gitea` (НЕ rootless: rootless усложняет ssh/тома, а ssh-контур
-  и так не вводится — D8).
-- **Пиннинг: точный неподвижный тег литералом в compose** (`image: <repo>:<x.y.z>`), не `latest`,
-  не плавающий мажор, не `${VERSION}`-интерполяция (версия — не операторская ручка; её смена =
-  осознанная правка bundle под тестом). Digest-пиннинг **не требуется**: тег + анти-дрейф формы
-  (TC-03: ни одного `:latest`/безтегового образа) достаточны для NFR-6, digest нечитаем и
-  затрудняет осознанный апгрейд.
-- **Точные теги фиксирует developer при реализации по фактически проверенному стенду** (ADR
-  сознательно не выдумывает номера версий — ложная точность хуже честной отсылки к référence);
-  обновление версий после ORCH-103 — отдельные задачи (BRD §6).
-- Healthchecks: у инфра-сервисов (postgres/redis/minio/gitea) — стандартные; у Plane-сервисов —
-  что даёт upstream; недостающее добирает poll-ожидание bootstrap (D5).
-
-### D4 — Сеть: одна bridge, сервис-DNS внутрь, публикация только человеческих портов (OQ-5)
-
-- **Вся инсталляция — в одной именованной bridge-сети** compose-проекта. `network_mode: host`
-  в bundle **не используется** ни для кого: он был нужен нашему контуру ради ssh-деплоя в
-  127.0.0.1 (ORCH-036/058) — в bundle эти пути структурно неактивны (`ORCH_DEPLOY_SSH_HOST`
-  пуст → freshness/self-deploy/build-cache-pruner no-op по построению).
-- **Машинный трафик — строго сервис-DNS:** Plane→орк webhook `http://orchestrator:8500/webhook/plane`,
-  Gitea→орк `http://orchestrator:8500/webhook/gitea`, орк→Plane `ORCH_PLANE_API_URL=http://<plane-proxy-svc>`,
-  орк→Gitea `ORCH_GITEA_URL=http://gitea:3000`, watchdog→орк
-  `WATCHDOG_METRICS_URL=http://orchestrator:8500/metrics`. Никаких `host-gateway`/`extra_hosts`.
-- **Наружу публикуются только человеческие точки** (карта конфигурируема в bundle-каноне,
-  дефолты): Plane proxy → `${BUNDLE_PLANE_PORT:-8080}`, Gitea web → `${BUNDLE_GITEA_HTTP_PORT:-3000}`,
-  орк API → `${BUNDLE_ORCH_PORT:-8500}` (операторский smoke `curl /health`). **Postgres/redis/
-  mq/minio наружу НЕ публикуются** (секрет-гигиена/поверхность атаки).
-- **Публичные URL** (браузер оператора, ссылки в Plane-комментариях/Telegram) строятся от
-  **`BUNDLE_PUBLIC_HOST`** (дефолт `localhost`): `ORCH_GITEA_PUBLIC_URL=http://$BUNDLE_PUBLIC_HOST:3000`,
-  `ORCH_PLANE_WEB_URL=http://$BUNDLE_PUBLIC_HOST:8080`, WEB_URL Plane, ROOT_URL Gitea. Split
-  internal/public уже поддержан конфигом орка (ORCH-101) — новых ключей `src/**` не требуется.
-- **Мина Gitea закрывается явно:** Gitea по умолчанию запрещает webhook'и в приватные адреса —
-  bundle задаёт `GITEA__webhook__ALLOWED_HOST_LIST=orchestrator` (env-конфиг образа Gitea), иначе
-  R-4 «задача не появилась» гарантирован. Smoke (FR-6) проверяет оба направления.
-- HTTPS/домены/reverse-proxy заказчика — вне bundle (BRD §2.2); `BUNDLE_PUBLIC_HOST` +
-  документированный ручной шаг при необходимости.
-
-### D5 — Bootstrap: `scripts/bootstrap_bundle.py`, python stdlib, `plan`/`apply`/`verify` (OQ-4)
-
-- **Язык — python stdlib-only** (NFR-7; паттерн `gen_secrets.py`: работает на голом python3
-  целевого хоста ДО `docker compose up`; bash отвергнут — 9-шаговый stateful-визард с
-  таймаутами/JSON/чистыми функциями под unit-тесты на bash не тестируем структурно).
-  Никаких импортов из `src/**` (bootstrap бежит вне venv платформы; канон-знания — только
-  субпроцессами кирпичей, см. ниже).
-- **Режимы (паттерн ORCH-009):** `plan` — **дефолт**, ноль мутаций (печать плана + read-only
-  preflight-диагностика); `apply` — полный прогон; `verify` — read-only пост-проверка
-  (health/queue/metrics + `onboard_project.py verify` субпроцессом). Exit-коды: `0` успех /
-  `2` остановка на manual-step или незавершённое предусловие / `1` ошибка (контракт TRZ FR-2).
-- **Step-движок check→ensure:** каждый шаг = `check()` (выполнено?) → skip | `ensure()`
-  (доводка). Повторный `apply` на инициализированном bundle = каскад skip (AC-8);
-  «resume» после manual-step = просто повторный запуск. Чистые функции (preflight-вердикт,
-  сборка плана, рендер env-файлов) выделены для unit-тестов (TC-08).
-- **Последовательность apply (норматив TRZ FR-2, механика):**
-  1. **Preflight (fail-fast, до мутаций):** docker+compose есть; `deploy/bundled/.env` существует
-     и обязательные ключи заполнены (пути Claude CLI — существуют на хосте, иначе warning-блок:
-     стек поднимется, конвейер без LLM не поедет); целевые порты свободны; томов/контейнеров с
-     префиксом `orchestrator-bundle` нет (иначе — явный «уже инициализирован, продолжаю в
-     ensure-режиме» либо отказ при противоречивом состоянии); RAM/диск ≥ минимумов из
-     BUNDLED_SETUP (пороги — константы скрипта, синхронизированы с доком); python3+venv доступны.
-  2. **Секреты (FR-3):** webhook-секреты — **субпроцессом `scripts/gen_secrets.py --write <tmp>`**
-     (не реализуются заново, AC-7); bundle-внутренние (пароли postgres/redis/mq/minio,
-     SECRET_KEY Plane, админ-пароль Gitea) — stdlib `secrets`; запись в `deploy/bundled/.env` +
-     корневой `.env`; существующие значения не перетираются без `--force-secrets`; значения
-     в stdout/лог **не печатаются** (только имена ключей).
-  3. **Up + готовность:** `docker compose -f deploy/bundled/docker-compose.yml up -d`
-     (идемпотентен по построению — оба прочтения AC-1 истинны: оператор мог выполнить up сам);
-     ожидание готовности poll-циклами с таймаутами (health контейнеров, `migrator` завершился
-     `exit 0`, HTTP-пробы Plane/Gitea); по таймауту — диагностика «какой сервис не дождались +
-     хвост его логов».
-  4. **Init Gitea — полностью автоматом** (D6).
-  5. **Init Plane — manual-step чекпоинты** (D7).
-  6. **Онбординг sandbox-проекта — строго `onboard_project.py apply` + `verify`** (D7).
-  7. **Git-доступ агентов** (D8) + клон sandbox-репо в `deploy/bundled/repos/`.
-  8. **Конфиг орка:** сборка корневого `.env` (база — канон `.env.example`: URL'ы D4, токены,
-     секреты, `ORCH_PROJECTS_JSON` из вывода onboard; `ORCH_DEPLOY_SSH_HOST=` пусто —
-     деплой-машинерия спит) и `.env.watchdog` (база — `.env.watchdog.example`; Telegram-ключи
-     опциональны — пусто = деградация только нотификаций); пересоздание
-     `up -d orchestrator orchestrator-watchdog` для подхвата env.
-  9. **Health + итог:** `GET /health`, `/queue`, `/metrics`; финальная сводная таблица PASS/FAIL
-     по шагам; следующая команда оператора — smoke BUNDLED_SETUP §smoke (REPLICATION §4).
-- **Контракт manual-step (fail-safe, BR-2):** печать точной инструкции (URL/что нажать/что
-  ввести) → ожидание подтверждения (интерактивно при TTY; без TTY — немедленный `exit 2` с той
-  же инструкцией) → **верификация результата API-пробой** (например, валидность введённого
-  `ORCH_PLANE_API_TOKEN` запросом к workspace) → только затем продолжение. Молчаливый пропуск
-  запрещён.
-- **Запретов в скрипте нет:** delete-операций (`docker volume rm`/`rm -rf`/`down -v`) — **ноль**
-  (teardown — D9); боевых литералов FORBIDDEN — ноль (TC-06); печати секретов — ноль (NFR-3);
-  наш прод недостижим по построению (скрипт говорит только с локальным docker целевого хоста).
-
-### D6 — Init Gitea: полностью автоматизирован, branch protection НЕ настраивается (OQ-3-часть)
-
-- Административная учётка — **официальный CLI в контейнере**:
-  `docker compose … exec gitea gitea admin user create --admin …` (idempotent: предсуществование
-  пользователя → skip); API-токен — `gitea admin user generate-access-token` (или REST под basic
-  auth — равнозначно, выбирает developer по фактической версии Gitea) → `ORCH_GITEA_TOKEN`.
-- **Один пользователь-бот** — владелец (`ORCH_GITEA_OWNER`) sandbox-репо и носитель токена для
-  API орка и token-remote агентов (D8). Отдельная россыпь пользователей на тестовый bundle —
-  неоправданная сложность (зафиксировано как осознанный компромисс в 10-tech-risks TR-7).
-- **Branch protection на `main` НЕ включается; pre-receive не вводится** — норматив D10 ORCH-009 /
-  adr-0037 п.4 (ломают PR-merge API merge-актора, INV-4); bundle-Gitea конфигурируется тем же
-  правилом, BUNDLED_SETUP фиксирует его явно (ссылкой на LITE_SETUP §6, не копией).
-- `GITEA__webhook__ALLOWED_HOST_LIST=orchestrator` — см. D4.
-
-### D7 — Init Plane: честные manual-step + онбординг строго кирпичом (OQ-3)
-
-- **Не автоматизируется (CE):** instance-setup/первый админ, создание workspace
-  (`ORCH_PLANE_WORKSPACE_SLUG`), выпуск `ORCH_PLANE_API_TOKEN` — три **manual-step чекпоинта**
-  контракта D5 (инструкция → подтверждение → API-верификация). **Прогрессивная автоматизация
-  разрешена:** если на момент реализации у конкретной пиннованной версии Plane CE обнаружится
-  стабильный API/seed-механизм для шага — developer вправе заменить manual-step на ensure **без
-  изменения контракта чекпоинта** (верификация результата остаётся той же) и без правки ADR.
-- **Онбординг sandbox-проекта — ТОЛЬКО субпроцессом** `python3 scripts/onboard_project.py apply`
-  + `verify` из **host-venv чекаута** (канон запуска — ONBOARDING.md: venv с `requirements.txt`;
-  создание venv — ensure-шаг bootstrap). Env для субпроцесса (URL'ы/токены D4) bootstrap передаёт
-  через окружение процесса (pydantic env-переменные перекрывают `env_file`) — корневой `.env` к
-  этому моменту уже собран либо передаётся фрагментом. Собственная реализация статусов/лейблов/
-  webhook в bootstrap **запрещена** (BR-6/AC-7; 22 статуса остаются за
-  `plane_sync._PLANE_NAME_TO_KEY`).
-- **Workspace-webhook Plane** (Plane→орк) — остаётся manual-step **самого onboard-CLI**
-  (его шаг `plane.workspace-webhook` уже MANUAL — CE не даёт API); bootstrap лишь подставляет
-  правильный in-network URL `http://orchestrator:8500/webhook/plane` и секрет-имя в инструкцию
-  и верифицирует доставку на smoke (FR-6).
-- `--webhook-url` для Gitea per-repo hook — `http://orchestrator:8500/webhook/gitea` (D4).
-
-### D8 — Git-доступ агентов: HTTP token-remote; ssh-контур не вводится (OQ-6)
-
-- Клон sandbox-репо в `deploy/bundled/repos/<repo>` с remote-URL вида
-  `http://<token>@gitea:3000/<owner>/<repo>.git` — **паттерн уже в каноне**
-  (`onboard_project.py::_push_url` делает initial push именно так); агенты наследуют origin
-  чекаута (push/fetch из контейнера — bridge-DNS, D4).
-- **Ssh-контур в bundle не вводится:** ssh-порт Gitea не публикуется, маунт `ORCH_HOST_SSH_DIR`
-  в bundle-compose отсутствует (это нашему контуру нужен ssh к хосту/Gitea; в bundle —
-  лишняя поверхность: генерация ключей, known_hosts, регистрация в Gitea).
-- Компромисс «токен в `.git/config` plaintext» зафиксирован честно: каталог `deploy/bundled/repos`
-  — локальный, права на токен-носители `600`, токен — бот-юзера одной тестовой инсталляции;
-  риск/митигейшн — 10-tech-risks TR-7. Git-идентичность агентов — существующие
-  `ORCH_AGENT_GIT_NAME`/`ORCH_GIT_EMAIL_DOMAIN` (дефолты годятся).
-
-### D9 — Teardown: только документированная процедура, не режим скрипта (OQ-7)
-
-`BUNDLED_SETUP.md` §13 «Остановка и полный сброс»: `docker compose -f … down` (остановка) /
-`down -v` + удаление сгенерённых конфигов и `deploy/bundled/{data,repos}` (полный сброс) — с
-явным предупреждением о необратимости. **Reset-режим в bootstrap отвергнут:** одна опечатка
-флага = снос томов; ценность против fenced-команды — нулевая; зато скрипт получает структурную
-гарантию «delete-операций НЕТ вообще» (упрощение TC-07 и ревью).
-
-### D10 — Док-канон: `docs/deployment/BUNDLED_SETUP.md`, 14 разделов, ссылки вместо форка (FR-4)
-
-Форма — канон LITE_SETUP (adr-0037 D2): нормативные разделы в порядке маршрута оператора,
-каждый исполняемый шаг = fenced-команда + «Проверка:» PASS/FAIL, хост-специфика — только
-плейсхолдеры. **14 разделов** (норматив; точные заголовки — за developer'ом, проверяемость —
-структурный тест): (1) рамка Bundled (включая «что НЕ входит»: Claude CLI, Telegram, HTTPS;
-границы vs Lite); (2) **требования к хосту** (RAM/диск/CPU **по замеру тестового развёртывания**,
-карта портов D4, явное «Plane ≈ 14 контейнеров — ресурсоёмко»); (3) предусловия;
-(4) получение кода; (5) секреты; (6) запуск bundle-compose; (7) bootstrap (+ перечень
-manual-step Plane); (8) LLM — ссылкой на LITE_SETUP §7; (9) Telegram — ссылкой на LITE_SETUP §8;
-(10) онбординг следующих проектов — ссылкой на ONBOARDING.md; (11) smoke — шаги REPLICATION §4;
-(12) stateless-проверка; (13) остановка/полный сброс (D9); (14) траблшутинг (минимум: webhook
-не доходит — включая `ALLOWED_HOST_LIST`, OOM/нехватка RAM, порт занят, claude не найден,
-Plane-миграции не завершились). Fail-closed имена `Confirm Deploy`/`STOP` и «22 статуса» —
-сверкой импорта в тесте, не литералом. `docs/operations/REPLICATION.md` §1: строка Type B →
-✅ ORCH-103 + ссылка. **Норматив сопровождения (NFR-5):** изменил шаги Bundled-тиража → обнови
-BUNDLED_SETUP.md в том же PR.
-
-### D11 — Анти-дрейф: три структурных тест-модуля (FR-5; без docker/сети/LLM)
-
-По тест-плану `04-test-plan.yaml` (имена модулей — норматив): `tests/test_bundle_compose.py`
-(TC-01…04: yaml.safe_load, обязательные сервисы, заморозка корневого compose зеркалом
-существующего ассерта, пины образов, префикс томов, key-set-sync `${VAR}` ⊆
-`deploy/bundled/.env.example`), `tests/test_bundled_setup_doc.py` (TC-05/06/09/10/11: разделы
-D10, FORBIDDEN — **импорт** из `test_no_host_hardcodes.py`, секрет-эвристика hex≥32/alnum≥40 —
-паттерн D8 ORCH-102, env-ключи ⊆ канонов, число статусов — импортом `plane_sync`, кросс-рефы,
-CHANGELOG), `tests/test_bootstrap_script.py` (TC-07/08: ссылки на кирпичи, отсутствие
-delete-операций и собственного списка статусов, unit чистых функций preflight/плана/рендера,
-контракт exit 0/2/1). Существующие анти-дрейф тесты остаются зелёными **без правки их ассертов**
-(AC-5/AC-6).
-
-## Альтернативы
-
-- **Расширить корневой `docker-compose.yml` (профиль `bundled`)** — отвергнуто: заморожен
-  анти-дрейфом ORCH-102 (TC-04) и нормативом adr-0037 п.2 «compose не форкается»; смешение
-  боевого контура с дистрибутивом = групповой риск self-hosting.
-- **Include-композиция (`include:`/несколько `-f`)** — отвергнуто: многофайловость = новые
-  степени свободы запуска (забытый `-f` молча меняет состав), сложнее структурный тест; один
-  самодостаточный файл проще и детерминированнее (NFR-6).
-- **Live env через `--env-file deploy/bundled/.env.bundled`** — отвергнуто: footgun голой
-  compose-команды без флага (молчаливые дефолты) — см. D2.
-- **Орк в bundle под `network_mode: host` + `host-gateway` для webhook'ов** — отвергнуто:
-  хост-сеть нужна была нашему ssh-деплой-контуру, который в bundle спит; bridge даёт чистые
-  стабильные сервис-DNS-URL обоих направлений и нулевые порт-конфликты (D4).
-- **Digest-пиннинг образов** — отвергнуто: нечитаем, усложняет осознанный апгрейд; неподвижный
-  тег + тест формы достаточны для NFR-6 (D3).
-- **Ssh-доступ агентов к bundle-Gitea** — отвергнуто: три лишних механизма (ключи, known_hosts,
-  регистрация) против уже существующего token-remote-паттерна onboard (D8).
-- **Bash-bootstrap** — отвергнуто: нет unit-тестируемых чистых функций (TC-08), JSON/поллинг/
-  стейт-машина шагов на bash хрупки (D5).
-- **Reset-режим bootstrap** — отвергнуто: риск-поверхность против нулевой ценности (D9).
-- **Переписать Plane-стек «по-своему» (свои имена сервисов/env)** — отвергнуто: дрейф от
-  upstream-доков, неоплачиваемое сопровождение (D3).
-
-## Последствия
-
-- **+** Эпик ORCH-10 закрывается по типу B: заказчик без инфраструктуры получает конвейер
-  «под ключ» одной командой + одним bootstrap-прогоном с честными чекпоинтами.
-- **+** Нулевой дрейф канонов: статусы/лейблы/секреты/smoke/док-форма — переиспользованы
-  (gen_secrets, onboard_project, REPLICATION §4, форма LITE_SETUP); рантайм байт-в-байт.
-- **+** Наш прод недостижим по построению: артефакты инертны в нашем контуре, kill-switch не
-  нужен (паттерн ORCH-009); все существующие анти-дрейф тесты остаются зелёными.
-- **−** Новая поверхность сопровождения: пиннованные версии Plane/Gitea стареют (апгрейд —
-  отдельные задачи, NFR-6); двойной `.env`-слой (bundle-инфра vs runtime орка) требует
-  дисциплины «писатель — bootstrap» (митигировано D2: один писатель + key-sync тест).
-- **−** Manual-step Plane CE размывают UX «одной команды» — неустранимо честно (CE без API
-  первичной инициализации); митигировано контрактом чекпоинта (инструкция+верификация) и
-  прогрессивной автоматизацией (D7).
-- **−** Токен в remote-URL агентских чекаутов — осознанный компромисс тестовой инсталляции
-  (TR-7; права 600, непубликуемые порты БД, один бот-юзер).
-- **Откат:** удалить `deploy/`, `scripts/bootstrap_bundle.py`, `docs/deployment/BUNDLED_SETUP.md`,
-  три тест-модуля, строку REPLICATION §1 и записи CHANGELOG/CLAUDE.md/README — состояние репо 1:1
-  (docs+scripts+tests, без миграций); на целевых хостах — процедура §13 (D9).
-
-## Ссылки
-
-- BRD: `docs/work-items/ORCH-103/01-brd.md`
-- TRZ: `docs/work-items/ORCH-103/02-trz.md` (OQ-1…OQ-7 → D1…D9)
-- Acceptance: `docs/work-items/ORCH-103/03-acceptance-criteria.md`; тест-план: `04-test-plan.yaml`
-- Сквозной ADR: `docs/architecture/adr/adr-0038-bundled-replication-canon.md`
-- Предшественники: adr-0035 (ORCH-009 onboarding: D10 branch-protection, manual-step, `_push_url`),
-  adr-0036 (ORCH-101 10-common: параметризация/«дефолт=боевое»/gen_secrets/REPLICATION),
-  adr-0037 (ORCH-102 Lite: док-канон/`.env.watchdog.example`/compose-подмножество)
-- Сверено по коду/репо: `tests/test_lite_setup_doc.py` (заморозка корневого compose, FORBIDDEN-импорт,
-  секрет-эвристика), `tests/test_no_host_hardcodes.py` (`FORBIDDEN`), `scripts/gen_secrets.py`
-  (`--write PATH`, exit 0/2), `scripts/onboard_project.py` (закрытый src-импорт-лист, MANUAL
-  `plane.workspace-webhook`, `_push_url`, exit 0/2/1), `docs/operations/ONBOARDING.md` (host-venv),
-  `docker-compose.yml` (паттерны `${VAR:-default}`, `env_file required:false`, группа ORCH-040),
-  `.gitignore` (неякорные `.env`/`data/`/`.env.watchdog`)

docs/work-items/ORCH-103/07-infra-requirements.md

@@ -1,73 +0,0 @@
----
-work_item: ORCH-103
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-11
-model_used: claude-opus-4-8
----
-
-# 07 — Инфра-требования: ORCH-103 — Bundled-тираж: весь стек одним комплектом + bootstrap
-
-Work Item: **ORCH-103** · Repo: **orchestrator** · Стадия: architecture
-
-> Вся инфраструктура этой задачи — **ЦЕЛЕВОЙ хост заказчика** (и одноразовый тестовый хост/VM
-> приёмки). Инфраструктура НАШЕГО прод-контура (mva154) не затрагивается ни одним пунктом:
-> артефакты bundle в нашем контуре инертны (NFR-2, паттерн ORCH-009).
-
-## I-1. Топология / окружения
-
-**Наш контур: N/A** (корневой `docker-compose.yml`, прод 8500, staging 8501 — байт-в-байт).
-
-**Целевой хост bundle (нормативно, ADR-001 D1/D3/D4):**
-- Один Linux x86_64 хост, docker + docker compose v2, sudo у оператора. Compose-проект
-  **`orchestrator-bundle`** (`deploy/bundled/docker-compose.yml`), одна именованная bridge-сеть.
-- Состав: `orchestrator` (build из корневого `Dockerfile`), `orchestrator-watchdog`
-  (build из `watchdog/Dockerfile`), `gitea` (пиннованный `gitea/gitea`), Plane CE-стек —
-  зеркало upstream selfhost-référence (≈13–14 сервисов: web/space/admin/api/worker/beat-worker/
-  migrator/live + postgres/redis/mq/minio/proxy; точные теги пиннит developer по проверенному
-  стенду). Staging-контур орка отсутствует.
-- **Карта портов (дефолты; конфигурируемы в `deploy/bundled/.env.example`):**
-  `${BUNDLE_ORCH_PORT:-8500}` — API орка (smoke/health), `${BUNDLE_PLANE_PORT:-8080}` — Plane
-  proxy (UI), `${BUNDLE_GITEA_HTTP_PORT:-3000}` — Gitea web. Postgres/redis/mq/minio/ssh-Gitea —
-  **наружу не публикуются**. Машинный трафик (webhooks в обе стороны, API, git, /metrics) —
-  внутрисетевой сервис-DNS.
-- **Хранилище:** состояние Plane/Gitea — именованные тома `orchestrator-bundle_*`; данные орка —
-  bind `deploy/bundled/data`; репозитории агентов — bind `deploy/bundled/repos` (владелец —
-  uid оператора = `ORCH_RUN_UID`, инвариант ORCH-040).
-- **Ресурсы (предусловие, гипотеза BRD §6 — финальные цифры по замеру на приёмке, AC-4):**
-  ориентир ≥ 4 vCPU / 8 GB RAM / 40 GB диска; preflight bootstrap проверяет и отказывает до
-  любых мутаций (BR-7).
-
-## I-2. Переменные окружения / секреты
-
-- **Новый канон:** `deploy/bundled/.env.example` (bundle-инфра: `BUNDLE_PUBLIC_HOST`, карта
-  портов, реюз `ORCH_RUN_UID/GID`/`ORCH_DOCKER_GID`/`ORCH_AGENT_HOME_DIR`/`ORCH_HOST_CLAUDE_*`,
-  плейсхолдеры внутренних кред Plane/Gitea по upstream-именам). Live-файлы только на целевом
-  хосте, права 600: `deploy/bundled/.env`, корневые `.env`/`.env.watchdog` (каноны Lite 1:1).
-- **Корневой `.env.example` НЕ меняется** (bundle не вводит новых ключей `Settings`); в
-  `.gitignore` добавляется `deploy/bundled/repos/` (остальные live-файлы уже покрыты неякорными
-  `.env`/`data/`/`.env.watchdog`).
-- **Секреты (FR-3):** webhook-секреты — `gen_secrets.py`; внутренние креды стека (postgres/
-  redis/mq/minio/SECRET_KEY Plane, админ Gitea) — stdlib `secrets` в bootstrap; внешние
-  предусловия заказчика — Claude CLI/Anthropic-доступ (обязателен для конвейера),
-  Telegram-токены (опциональны). В репо и логах bootstrap секретов нет (NFR-3, тест-эвристика).
-
-## I-3. Деплой / рестарт
-
-- **Наш прод: рестарт НЕ требуется и НЕ выполняется.** Задача — docs+scripts+compose+tests;
-  мерж в `main` ничего не активирует в нашем контуре (никто не исполняет bundle-артефакты;
-  kill-switch не нужен — паттерн ORCH-009). Self-hosting инвариант соблюдён по построению.
-- На целевом хосте пересоздание контейнеров орка/watchdog после сборки env — штатный шаг
-  bootstrap (D5 шаг 8); к нашему проду отношения не имеет.
-
-## I-4. CI/CD
-
-- `.gitea/workflows/**` — **без изменений**; три новых структурных тест-модуля подхватываются
-  существующим `pytest tests/ -q` (без docker/сети/LLM — CI-безопасны, TC-12).
-
-## I-5. Разовое предусловие приёмки (человек)
-
-Чистый тестовый Linux-хост/VM (ресурсы I-1) для ручной приёмки AC-1/AC-2/AC-3/AC-8 по
-`BUNDLED_SETUP.md` + замер фактических минимумов RAM/диск/CPU для §2 дока (AC-4: цифры «не с
-потолка»). На нашем боевом хосте bundle не запускается ни в каком виде (BRD §2.2).

docs/work-items/ORCH-103/10-tech-risks.md

@@ -1,42 +0,0 @@
----
-work_item: ORCH-103
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: 2026-06-11
-model_used: claude-opus-4-8
----
-
-# 10 — Технические риски: ORCH-103 — Bundled-тираж: весь стек одним комплектом + bootstrap
-
-Work Item: **ORCH-103** · Repo: **orchestrator** · Стадия: architecture
-
-> Информационный (гейтом не парсится). Риски реализации и эксплуатации bundle; решения —
-> `06-adr/ADR-001-bundled-stack-compose-and-bootstrap.md` (D1…D11).
-
-## Реестр рисков
-
-| ID | Риск | Вер. | Влия. | Митигейшн |
-|----|------|------|-------|-----------|
-| TR-1 | **Ресурсоёмкость Plane** (≈13–14 контейнеров): OOM/вечные миграции на слабом хосте → «bundle не работает» | Сред. | Выс. | Preflight bootstrap (RAM/диск/CPU до мутаций, BR-7); честные цифры в BUNDLED_SETUP §2 **по замеру** (AC-4); таймауты ожидания готовности с диагностикой «кто не дождался + хвост логов» (D5 ш.3); траблшутинг §14 |
-| TR-2 | **Дыры Plane CE API**: instance-setup/workspace/API-токен UI-only → UX «одной команды» размывается; молчаливый пропуск шага ломает всё дальше | Выс. | Сред. | Контракт manual-step (инструкция → подтверждение → **API-верификация результата**, exit 2 без TTY; D5/D7); число ручных шагов минимизировано (Gitea — полностью автоматом, D6); прогрессивная автоматизация разрешена без смены контракта |
-| TR-3 | **Дрейф upstream-образов**: «плавающий» тег ломает воспроизводимость; пиннованные версии стареют (CVE/несовместимость) | Сред. | Сред. | Неподвижные теги литералом + тест формы TC-03 (не `latest`/безтеговых); теги фиксируются по фактически проверенному стенду (D3); апгрейд — отдельные задачи (NFR-6, BRD §6) |
-| TR-4 | **Сетевая недостижимость вебхуков** (труднодиагностируемое «задача не появилась»): приватные адреса, рассинхрон URL | Сред. | Выс. | Одна bridge-сеть + строго сервис-DNS для машинного трафика (D4); **явный `GITEA__webhook__ALLOWED_HOST_LIST=orchestrator`** (Gitea по умолчанию режет приватные таргеты); URL подставляет bootstrap, не оператор; smoke проверяет ОБА направления (FR-6); траблшутинг §14 |
-| TR-5 | **Соблазн форкнуть/расширить корневой compose** (упадёт анти-дрейф ORCH-102 TC-04) | Низ. | Выс. | Bundle строго отдельным файлом `deploy/bundled/` (D1); TC-02 зеркалит заморозку корневого compose; правило эскалации TRZ §7 — если всплывёт незакрытая параметризация `src/**`, остановиться и вернуть задачу, не «дотачивать молча» |
-| TR-6 | **Утечка секретов** в репо/логи при генерации bundle-кред | Низ. | Выс. | В гите — только плейсхолдеры (канон D2); bootstrap не печатает значения (имена ключей/пути, D5); права 600; секрет-эвристика hex≥32/alnum≥40 + FORBIDDEN-скан на новых артефактах (TC-06); live-файлы в `.gitignore` |
-| TR-7 | **Токен-remote агентов**: токен бот-юзера plaintext в `.git/config` чекаутов; один бот = широкие права | Сред. | Низ. | Осознанный компромисс тестовой инсталляции (D8): порты БД/брокера не публикуются, каталог локальный, права 600; ssh-контур сознательно не вводится (меньше поверхность); зафиксировано в BUNDLED_SETUP §1 «рамка» |
-| TR-8 | **Путаница двух `.env`-слоёв** (bundle-инфра `deploy/bundled/.env` vs runtime орка корневой `.env`): ручная правка не того файла | Сред. | Сред. | Bootstrap — **единственный писатель** всех live-файлов (D2); авто-чтение compose из project dir (нет `--env-file`-футгана); шапки-комментарии в канонах перекрёстно ссылаются; key-set-sync тест TC-04 |
-| TR-9 | **Хост-python/venv для onboard**: `onboard_project.py` требует venv с `requirements.txt` (канон ONBOARDING) — на голом хосте шаг 6 падает | Сред. | Сред. | Preflight проверяет python3/venv (D5 ш.1); создание venv — идемпотентный ensure-шаг bootstrap; сам bootstrap stdlib-only и от venv не зависит (D5) |
-| TR-10 | **Повторный запуск/грязный хост**: bootstrap портит чужое состояние или дублирует своё | Низ. | Выс. | Step-движок check→ensure (skip-семантика, AC-8); детект «грязи» по префиксу `orchestrator-bundle` до мутаций; delete-операций в скрипте нет вообще — teardown только документированной процедурой §13 (D9); unit-тесты чистых функций preflight (TC-08) |
-
-## Сводный вывод
-
-Доминирующий класс — **эксплуатационные риски целевого хоста** (TR-1/TR-2/TR-4): они не
-затрагивают наш прод и гасятся честным preflight, контрактом manual-step и smoke в обе стороны.
-Рисков для прод-конвейера self-hosting **нет по построению** (NFR-1/NFR-2: рантайм байт-в-байт,
-артефакты в нашем контуре инертны, kill-switch не требуется — паттерн ORCH-009; все существующие
-анти-дрейф тесты остаются зелёными). Эскалация `arch:major-change` не требуется: новых стадий/
-компонентов рантайма/смены БД нет — задача целиком в слое дистрибуции (паттерн ORCH-101/102).
-Возврат в анализ не требуется: ТЗ выполнимо без нарушения принципов; единственный заранее
-оговорённый стоп-кран — TR-5 (обнаружение незакрытой параметризации `src/**` ⇒ остановка по
-TRZ §7). Остаточный риск — **низкий**.

docs/work-items/ORCH-103/12-review.md

@@ -1,160 +0,0 @@
----
-verdict: APPROVED
-work_item: ORCH-103
-stage: review
-author_agent: reviewer
-status: approved
-created_at: 2026-06-11
-model_used: claude-opus-4-8
-type: review
-work_item_id: ORCH-103
-version: 1
----
-
-# Review ORCH-103 — ORCH-10b Bundled-тираж: весь стек одним комплектом + bootstrap-скрипт
-
-> Машинный вердикт читается ТОЛЬКО из `verdict:` во frontmatter.
-
-## Summary
-
-PR закрывает Type B эпика ORCH-10 строго по ТЗ и ADR-001 (D1–D11): новый каталог
-`deploy/bundled/` (самодостаточный compose 16 сервисов, project name `orchestrator-bundle`,
-пиннинг неподвижными тегами, одна bridge-сеть, только человеческие порты, мина
-`GITEA__webhook__ALLOWED_HOST_LIST` закрыта), `scripts/bootstrap_bundle.py` (stdlib-only,
-`plan`-дефолт/`apply`/`verify`, step-движок check→ensure, exit 0/2/1, ноль delete-операций),
-конфиг-канон `deploy/bundled/.env.example` (ни одного дефолтного пароля),
-`docs/deployment/BUNDLED_SETUP.md` (14 разделов канона D10) и три содержательных
-анти-дрейф тест-модуля. Рантайм байт-в-байт: `git diff main` не содержит `src/**`,
-корневого `docker-compose.yml`, `Dockerfile`, `.gitea/workflows/**` (AC-6 подтверждён
-diff-stat'ом). Полный регресс: **`pytest tests/ -q` → 1844 passed, 0 failed** (AC-5);
-существующие анти-дрейф тесты (`test_lite_setup_doc.py`, `test_no_host_hardcodes.py`,
-канон ORCH-009) не правились. Документация обновлена в том же PR по всем точкам §8 ТЗ.
-Findings — только P2/P3, блокеров нет → **APPROVED**.
-
-## Оси проверки
-
-### 1. Соответствие ТЗ (02-trz.md, 03-acceptance-criteria.md)
-
-- **FR-1** ✅ — отдельный bundle-compose; состав = ADR D1/D3 (тест
-  `test_bundle_has_exactly_the_adr_service_set` фиксирует множество); пиннинг всех сторонних
-  образов литералом (TC-03); тома — именованные с префиксом проекта + bind строго внутри
-  project dir (TC-04); достижимость в обе стороны — сервис-DNS (D4) + `ALLOWED_HOST_LIST`;
-  карта портов в доке §2, конфликт порта → отказ preflight; staging-контура нет вовсе.
-- **FR-2** ✅ — последовательность шагов 1–9 ТЗ воспроизведена 1:1 в `APPLY_STEPS`
-  (тест `test_apply_steps_match_normative_plan` держит соответствие нормативному плану);
-  идемпотентность — check→ensure/skip (AC-8 покрыт unit'ами resume/«противоречивое
-  состояние»); exit-контракт 0/2/1 (`test_exit_code_contract`); манифест manual-step честный:
-  инструкция → подтверждение → API-верификация, без TTY — немедленный exit 2.
-- **FR-3** ✅ — webhook-секреты строго субпроцессом `gen_secrets.py` (структурный тест);
-  bundle-креды — stdlib `secrets` (token_hex ≥16 байт, unit проверяет длину); в репо только
-  пустые плейсхолдеры (`test_bundle_secrets_in_example_are_empty_placeholders`); права 600;
-  без перетирания без `--force-secrets` (`test_merge_missing_secrets_never_overwrites_without_force`).
-- **FR-4** ✅ — BUNDLED_SETUP.md: все 14 разделов в порядке маршрута, fenced-команды +
-  «Проверка:»/PASS/FAIL в каждом исполняемом разделе, общие шаги ссылками на
-  LITE_SETUP §5–§8 / ONBOARDING / REPLICATION §4 (форк канона отсутствует), fail-closed имена
-  `Confirm Deploy`/`STOP` и «22 статуса» — сверкой импорта `plane_sync._PLANE_NAME_TO_KEY`.
-- **FR-5** ✅ — три модуля без docker/сети/LLM; FORBIDDEN — импорт из
-  `test_no_host_hardcodes.py` (один источник истины); секрет-эвристика hex≥32/alnum≥40 с
-  негативным самочеком (не-evergreen); key-set-sync `${VAR}` ⊆ bundle-канона; заморозка
-  корневого compose зеркалом ассерта ORCH-102.
-- **FR-6** ✅ — smoke = REPLICATION §4 поверх bundle (§11 дока, без форка), минимальный
-  сигнал «артефакты 01–04 в ветке» зафиксирован.
-- **AC-матрица:** AC-4…AC-9 в файловой/структурной части — PASS (TC-01…TC-12 зелёные).
-  AC-1/AC-2/AC-3/AC-8(повторный прогон) в e2e-части — **ручная приёмка** на чистом хосте/VM
-  по рамке самих AC (в CI docker/LLM не гоняются) — остаётся за стадией приёмки, см. P2-2.
-
-### 2. Соответствие ADR (06-adr/ADR-001, adr-0038)
-
-- D1–D11 реализованы без отклонений; сквозной `adr-0038-bundled-replication-canon.md` заведён.
-- **Прогрессивная автоматизация webhook (D7)** — единственное место, где реализация глубже
-  буквы ADR: `step_plane_webhook` регистрирует workspace-webhook прямой записью в Postgres
-  инсталляции. Сверено: это **не новый канон, а переиспользование** документированного
-  «пути Б» LITE_SETUP §5.4 (тот же INSERT-контракт, колонка-в-колонку), контракт чекпоинта
-  сохранён (верификация SELECT'ом; при отказе — fallback на честный manual-step с той же
-  проверкой), схема стабильна благодаря пину `v0.23.1`. D7 явно разрешает такую замену
-  manual-step → ensure «без правки ADR». Нарушения нет; в доке §7 чекпоинт 4 описан честно.
-- **Трассировка (TRACEABILITY):** правка чужого маркированного блока одна — строка Type B в
-  `REPLICATION.md` §1 (артефакт ORCH-101); это запланированная точка расширения, прямо
-  предписанная ТЗ FR-6/§8 — инвариант ORCH-101 не сломан. Остальные изменения аддитивны
-  (новые файлы / новые секции CLAUDE.md, README архитектуры, CHANGELOG).
-- Нормативы предшественников соблюдены: branch protection НЕ настраивается (D10 ORCH-009 /
-  INV-4 — явно в D6 и §14.6 дока), compose не форкается (adr-0037), «дефолт = боевое» не
-  нарушен (корневой `.env.example` не тронут).
-
-### 3. Качество кода
-
-- `pytest tests/ -q`: **1844 passed, 0 failed** (66s); новые тесты содержательные — unit'ы
-  чистых функций покрывают позитив/негатив/resume/противоречивое состояние, эвристики имеют
-  негативный самочек, ast-скан stdlib-allowlist реально закрыт.
-- Бизнес-логика скрипта аккуратная: never-print секретов в stdout (только имена ключей),
-  маскированный лог при падении clone (токен в URL не утекает в вывод), `_psql` через stdin
-  (секрет не в argv), fail-fast preflight до любых мутаций, диагностика «кто не дождался +
-  хвост логов». Не багфикс-трек (feature) — требование регресс-теста-фиксатора BR-4/ORCH-019
-  неприменимо.
-- Замечания P2/P3 — ниже; ни одно не ломает инварианты конвейера и не относится к рантайму
-  платформы (скрипт исполняется только оператором на целевом хосте).
-
-### 4. Документация — обязательная проверка
-
-Выполнена явно, см. раздел «Документация» ниже. Обновлено всё требуемое в том же PR.
-
-## Findings
-
-### P0 — Blocker
-- (нет)
-
-### P1 — Must fix
-- (нет)
-
-### P2 — Should fix
-- [ ] **P2-1. Секреты в argv субпроцессов** (`scripts/bootstrap_bundle.py`):
-  `step_init_gitea` передаёт `GITEA_ADMIN_PASSWORD` аргументом `--password` в
-  `docker compose exec gitea gitea admin user create …`, а `step_agent_git` — токен в
-  clone-URL аргументом `git clone http://oauth2:<token>@…`. Значения видимы в `ps` хоста на
-  время исполнения. Формально AC-8 («секрет виден в stdout/логе») не нарушен, но это против
-  духа NFR-3 (ТЗ FR-2) и непоследовательно с собственной argv-гигиеной скрипта (`_psql`
-  прогоняет секреты через stdin с явным комментарием «секреты не попадают в argv, NFR-3»).
-  Рекомендация: для clone — использовать `git -c credential.helper`/`GIT_ASKPASS` либо
-  дописать компромисс в TR-7 (10-tech-risks) и шапку скрипта; для `gitea admin user create`
-  альтернатив CLI мало — минимум зафиксировать окно экспозиции в TR-7. Не блокер: разовая
-  операция оператора на одноарендном целевом хосте, угроза-модель совпадает с уже
-  зафиксированным компромиссом TR-7.
-- [ ] **P2-2. Замер цифр «Требований к хосту» отложен на приёмку** (AC-4): BUNDLED_SETUP §2
-  декларирует «подтверждаются замером приёмочного развёртывания» — на момент ревью цифры
-  (8 GB / 40 GB / 4 vCPU) синхронизированы с константами preflight структурным тестом, но
-  фактический замер ещё не зафиксирован. По рамке 03-acceptance-criteria (e2e — ручная
-  приёмка вне CI) это допустимо, однако при ручной приёмке AC-1/AC-2 результат замера нужно
-  зафиксировать (13-test-report / 15-staging-log или правка §2), иначе FAIL-условие AC-4
-  «цифры с потолка» останется формально незакрытым.
-
-### P3 — Nice to have
-- [ ] **P3-1.** `step_plane_webhook`: `slug`/`secret` интерполируются в SQL-строку без
-  экранирования одинарных кавычек. Секрет — hex от `gen_secrets` (безопасен), slug —
-  операторский ввод; кавычка в slug уронит INSERT. Риск минимален (ON_ERROR_STOP +
-  fail-safe fallback на manual-step), но дешёвое `value.replace("'", "''")` сняло бы класс
-  целиком.
-- [ ] **P3-2.** `run_verify`: при одновременном health-FAIL и onboard `exit 2` функция
-  возвращает `EXIT_MANUAL` (2), маскируя ошибку (ожидался бы приоритет `1`). Поведенческая
-  мелочь read-only режима.
-
-## Документация
-
-| Артефакт | Статус |
-|----------|--------|
-| `CLAUDE.md` | ✅ новый раздел «Bundled-тираж (ORCH-103)» (паттерн ORCH-101/102) |
-| `docs/architecture/README.md` | ✅ блок Type B — Bundled рядом с 10-common/Lite |
-| `CHANGELOG.md` | ✅ запись `feat: ORCH-103` (детальная, D1–D11) |
-| `docs/operations/REPLICATION.md` §1 | ✅ Type B → ✅ ORCH-103 + ссылка на BUNDLED_SETUP.md |
-| `docs/deployment/BUNDLED_SETUP.md` | ✅ создан, 14 разделов канона D10, держится тестом |
-| ADR | ✅ work-item `06-adr/ADR-001-…` + сквозной `adr-0038-bundled-replication-canon.md` |
-| `07-infra-requirements.md`, `10-tech-risks.md` (TR-1…TR-9) | ✅ заведены архитектором, кросс-рефы из кода сходятся |
-| `.gitignore` | ✅ `deploy/bundled/repos/` (NFR-3) |
-| `README.md` «Известные ограничения» (ORCH-079) | ✅ проверено явно: PR не закрывает ни один из 3 открытых пунктов (Telegram 48h / intra-repo deps / пакетный автоном) — обновление витрины не требуется |
-
-`src/**` не изменён (PR — deploy/scripts/docs/tests), поэтому P0-правило «`src/` изменён без
-документации» неприменимо; документация при этом обновлена полностью.
-
-## Итог
-
-`verdict: APPROVED` — P0/P1 отсутствуют; P2-1/P2-2 и P3 рекомендуется снять follow-up'ом или
-при ручной приёмке Bundled-развёртывания (AC-1/AC-2/AC-3/AC-8 e2e-часть).

docs/work-items/ORCH-103/13-test-report.md

@@ -1,67 +0,0 @@
----
-result: PASS
-work_item: ORCH-103
-stage: testing
-author_agent: tester
-status: pass
-created_at: 2026-06-11
-model_used: claude-opus-4-8
-type: test-report
-work_item_id: ORCH-103
----
-
-# Test Report — ORCH-103 — ORCH-10b Bundled-тираж: весь стек одним комплектом + bootstrap-скрипт
-
-> Машинный вердикт читается ТОЛЬКО из `result:` во frontmatter (`check_tests_passed`).
-
-## Окружение
-- Python: 3.12.13
-- pytest: 8.3.3
-- Worktree: `/repos/_wt/orchestrator/feature_ORCH-103-orch-10b-bundled-bootstrap/` (ветка задачи, не общий чекаут)
-- Дата: 2026-06-11
-
-## Smoke API (read-only)
-| Endpoint | Результат |
-|----------|-----------|
-| `GET /health` | PASS — `{"status":"ok","service":"orchestrator"}` |
-| `GET /status` | PASS — активная задача ORCH-103 (`stage: testing`) видна |
-| `GET /queue` | PASS — валидный JSON; блок `serial_gate` присутствует (ORCH-088, `orchestrator.active_task = ORCH-103`), блок `auto_labels` присутствует |
-
-Смок-регресс ORCH-088: блок `serial_gate` присутствует в полезной нагрузке `/queue` наряду с `auto_labels` — регресса нет.
-
-## Результаты (покрытие каждого TC из 04-test-plan.yaml)
-
-| TC ID | Тип | Описание (кратко) | AC | Модуль | Результат |
-|-------|-----|-------------------|----|--------|-----------|
-| TC-01 | unit | Bundle-compose существует/парсится; обязательные сервисы (орк/watchdog/Gitea/Plane-стек); staging не в дефолтном up | AC-1 | test_bundle_compose.py | PASS |
-| TC-02 | unit | Корневой docker-compose.yml не изменён; нет подстрок plane/gitea (зеркало TC-04 lite) | AC-6 | test_bundle_compose.py | PASS |
-| TC-03 | unit | Все сторонние образы пиннованы (нет latest/безтегового) | AC-9 | test_bundle_compose.py | PASS |
-| TC-04 | unit | Тома именованные с bundle-префиксом, без bind прод-контура; key-set-sync `${VAR}` ⊆ bundle-канон | AC-9 | test_bundle_compose.py | PASS |
-| TC-05 | unit | BUNDLED_SETUP.md: обязательные разделы FR-4 (требования к хосту с цифрами/портами/~14 контейнеров, bootstrap, smoke, stateless, сброс, траблшутинг); fenced + «Проверка:» | AC-4 | test_bundled_setup_doc.py | PASS |
-| TC-06 | unit | Гигиена (док+compose+bootstrap): нет FORBIDDEN-литералов (импорт из test_no_host_hardcodes); нет секрет-литералов (hex≥32/alnum≥40) | AC-9 | test_bundled_setup_doc.py | PASS |
-| TC-07 | unit | Bootstrap ссылается на gen_secrets.py/onboard_project.py; нет своего списка статусов/лейблов; нет delete-операций в обычном прогоне | AC-7 | test_bootstrap_script.py | PASS |
-| TC-08 | unit | Чистые функции bootstrap: грязный хост → отказ ДО мутаций; чистый → план; контракт exit 0/2/1 | AC-8 | test_bootstrap_script.py | PASS |
-| TC-09 | unit | Каждый env-ключ из дока есть в `.env.example` ∪ bundle-канон; число статусов сверяется импортом `plane_sync._PLANE_NAME_TO_KEY` | AC-9 | test_bundled_setup_doc.py | PASS |
-| TC-10 | unit | Кросс-ссылки: BUNDLED_SETUP → LITE_SETUP/ONBOARDING/REPLICATION; REPLICATION §1 отметка Type B → ORCH-103 | AC-7 | test_bundled_setup_doc.py | PASS |
-| TC-11 | unit | CHANGELOG.md содержит запись ORCH-103 | AC-5 | test_bundled_setup_doc.py | PASS |
-| TC-12 | integration | Полный регресс `pytest tests/ -q` зелёный; существующие анти-дрейф (test_lite_setup_doc.py, test_no_host_hardcodes.py, канон ORCH-009) без правки ассертов | AC-5 | tests/ | PASS |
-
-Все 12 TC выполнены и сопоставлены с критериями приёмки 03-acceptance-criteria.md. Структурная/файловая часть AC-4…AC-9 покрыта зелёными TC-01…TC-12. e2e-часть AC-1/AC-2/AC-3/AC-8 (фактический подъём bundle на чистом хосте/VM) — ручная приёмка вне CI по рамке самих AC (docker/LLM в CI не гоняются), как зафиксировано в test-plan `scope/notes` и ревью P2-2.
-
-## Целевые модули ORCH-103 (детально)
-- `tests/test_bundle_compose.py` — 14 passed (TC-01..04)
-- `tests/test_bundled_setup_doc.py` — 16 passed (TC-05/06/09/10/11)
-- `tests/test_bootstrap_script.py` — 19 passed (TC-07/08)
-- Анти-дрейф (без правки ассертов): `tests/test_lite_setup_doc.py` — 26 passed; `tests/test_no_host_hardcodes.py` — 8 passed
-- Итого по целевому срезу: **88 passed, 0 failed** (0.91s)
-
-## Вывод pytest (полный регресс)
-```
-$ python -m pytest tests/ -v --tb=short
-...
-================== 1844 passed, 1 warning in 70.33s (0:01:10) ==================
-```
-- 1844 passed, 0 failed, 1 warning (Pydantic V2 deprecation, не относится к задаче).
-
-## Итог
-PASS — полный регресс зелёный (1844 passed / 0 failed), smoke read-only (`/health`, `/status`, `/queue` с блоками `serial_gate` и `auto_labels`) в норме, все 12 TC из 04-test-plan.yaml выполнены и сопоставлены с критериями приёмки. Задача переходит на `deploy-staging`.

docs/work-items/ORCH-103/15-staging-log.md

@@ -1,34 +0,0 @@
----
-staging_status: SUCCESS
-work_item: ORCH-103
-stage: deploy-staging
-author_agent: deployer
-status: success
-created_at: 2026-06-11
-model_used: claude-opus-4-8
-timestamp: 2026-06-10T23:15:16Z
-base_url: http://localhost:8501
----
-
-# Staging Gate Log
-
-Staging test suite completed against the live staging environment (`orchestrator-staging`,
-port 8501, mode=stub). Ran canonically **inside the container** via `docker exec` (ORCH-048)
-so the B6 registry-isolation check reads `.env.staging` from the running instance's own
-process-env.
-
-**Result: 8/10 checks PASS — exit code 0 → SUCCESS.**
-
-- REAL failed: none
-- All REAL checks (A1–A3 smoke, B4–B6 access incl. registry isolation, C7–C8 E2E
-  create-issue / trigger-pipeline) are green.
-
-INFRA-WAIVED: C9a Branch appears in orchestrator-sandbox, C9b Analyst job enqueued in staging queue (known sandbox-infra; real checks green)
-
-VERDICT: SUCCESS (exit 0) — C9a/C9b are the two known sandbox-infra checks (depend on SANDBOX
-bot accounts being project members, not on the pipeline) and are tolerated under ORCH-061
-waiver tolerance (`staging_infra_tolerance_enabled=True`) since every REAL check passed.
-
-ORCH-103 is a docs+tests + new `deploy/bundled/` and `scripts/bootstrap_bundle.py` change;
-`src/**`, the root compose, Dockerfile, `STAGE_TRANSITIONS`/`QG_CHECKS`/DB schema are untouched,
-so no runtime behaviour regression is expected — consistent with the all-green REAL checks.

onboarding/README.md

@@ -1,67 +0,0 @@
-# onboarding/ — turnkey-kit нового проекта (ORCH-009)
-
-Каркас (**kit**) нового репозитория, подключаемого к оркестратору, и словарь его параметризации.
-Всё под `onboarding/` предназначено **новому** репо; ничто отсюда **не исполняется рантаймом
-оркестратора** (граница физическая — ADR-001 D1 ORCH-009). Материализацию выполняет операторский
-CLI `scripts/onboard_project.py` (режимы `plan`/`apply`/`verify`); полный процесс — runbook
-`docs/operations/ONBOARDING.md`.
-
-## Состав
-
-```
-onboarding/
-  README.md            ← этот файл
-  placeholders.json    ← словарь плейсхолдеров (single source of truth, D2)
-  repo-skeleton/       ← дерево зеркалит целевой репо (FR-1)
-    .openclaw/agents/{analyst,architect,developer,reviewer,tester,deployer}.md
-    CLAUDE.md  AGENTS.md  CONTRIBUTING.md  README.md  CHANGELOG.md  .env.example
-    docs/ARCHITECTURE.md  docs/PIPELINE.md  docs/PRODUCT_VISION.md
-    docs/operations/INFRA.md
-    docs/architecture/adr/README.md
-    docs/work-items/.gitkeep  docs/history/.gitkeep
-```
-
-## Плейсхолдеры (D2)
-
-Синтаксис: `{{NAME}}` (верхний регистр, `[A-Z][A-Z0-9_]*`). Подстановка — тупой проход
-`str.replace` по словарю `placeholders.json`; после рендера обязательный скан на неразрешённые
-`{{…}}` (ошибка в `apply`/`verify`). Никаких шаблонизаторов и условной логики в kit — kit обязан
-быть тупым.
-
-Словарь — `placeholders.json`: `NAME → {description, required, default, example}`. Тесты держат
-**биекцию**: каждый плейсхолдер, встречающийся в kit, объявлен в словаре, и каждый объявленный —
-используется (`tests/test_onboarding_kit.py::test_placeholder_dictionary_bijection`).
-
-Расширение словаря = правка `placeholders.json` + kit + тестов **в одном PR**.
-
-## Правило «канон не форкается» (BR-2 / D3)
-
-| Класс | Файлы | Механизм |
-|---|---|---|
-| **Live-copy канона** (НЕ хранится в kit) | `docs/_templates/**` (16 скелетов), `docs/_standards/**` (3 стандарта) | копируются CLI **verbatim из рабочего чекаута репо оркестратора в момент материализации** |
-| **Параметризуемые шаблоны** (хранятся здесь) | 6 промптов, `CLAUDE.md`, `AGENTS.md`, `CONTRIBUTING.md`, `README.md`, `CHANGELOG.md`, `docs/ARCHITECTURE.md`, `docs/PIPELINE.md`, `docs/PRODUCT_VISION.md`, `docs/operations/INFRA.md`, `docs/architecture/adr/README.md`, `.env.example` | рендер `{{…}}` |
-| **Скелет-каркас** | `docs/work-items/.gitkeep`, `docs/history/.gitkeep` | копия как есть |
-
-Канон копируется байт-в-байт, без переписывания: примеры конкретных work item внутри стандартов
-остаются иллюстрацией, не «утечкой». Утечка — это литерал оркестратора там, где должен быть
-параметр (чужой префикс work-item, порты оркестратора, его правила эксплуатации) — ловится
-тестом анти-утечек.
-
-Обновление канона в уже-онбордженных репо едет их обычными PR с reviewer-gate; новые онбординги
-автоматически получают свежий канон (live-copy).
-
-## Языковая политика промптов (D9)
-
-Канон: **5 промптов ru + `deployer.md` en** (deployer — самый safety-critical промпт; en-раскладка
-минимизирует регресс-поверхность байт-точных verdict-ключей и shell-команд). Per-project
-отступление — только решением в собственном ADR нового проекта (см. шаблон `CONTRIBUTING.md`).
-
-## Тесты kit
-
-```bash
-pytest tests/test_onboarding_kit.py tests/test_onboarding_script.py tests/test_onboarding_invariants.py -q
-```
-
-Структурные тесты канона 52d/92 гоняются по `onboarding/repo-skeleton/.openclaw/agents/*.md`
-**отдельно** от живых промптов оркестратора (`tests/test_agent_prompts_canon.py`) — это разные
-деревья с разными требованиями (kit параметризован, живые промпты — нет).

onboarding/placeholders.json

@@ -1,62 +0,0 @@
-{
-  "PROJECT_NAME": {
-    "description": "Человекочитаемое имя проекта (Plane-проект, README, паспорт)",
-    "required": true,
-    "default": null,
-    "example": "enduro-trails"
-  },
-  "PROJECT_DESCRIPTION": {
-    "description": "1–2 фразы «зачем проект» (README, PRODUCT_VISION, паспорт)",
-    "required": true,
-    "default": null,
-    "example": "Каталог эндуро-маршрутов с картой, треками и сезонностью"
-  },
-  "REPO": {
-    "description": "Имя Gitea-репозитория (== каталог под /repos)",
-    "required": true,
-    "default": null,
-    "example": "enduro-trails"
-  },
-  "GITEA_OWNER": {
-    "description": "Owner/организация репозитория в Gitea",
-    "required": true,
-    "default": "admin",
-    "example": "admin"
-  },
-  "WORK_ITEM_PREFIX": {
-    "description": "Префикс work-item проекта (идентификатор Plane-проекта, аналог ET)",
-    "required": true,
-    "default": null,
-    "example": "ET"
-  },
-  "PLANE_PROJECT_ID": {
-    "description": "UUID Plane-проекта (становится известен после Plane-шага apply)",
-    "required": true,
-    "default": null,
-    "example": "7a79f0a9-5278-49cd-9007-9a338f238f9c"
-  },
-  "STACK": {
-    "description": "Стек проекта, описательно (язык, фреймворк, БД)",
-    "required": true,
-    "default": null,
-    "example": "Python 3.12 + FastAPI + SQLite"
-  },
-  "TEST_CMD": {
-    "description": "Команда запуска тестов проекта (используется агентами developer/tester)",
-    "required": true,
-    "default": null,
-    "example": "pytest tests/ -q"
-  },
-  "PROD_PORT": {
-    "description": "Порт прод-контейнера проекта",
-    "required": true,
-    "default": null,
-    "example": "8600"
-  },
-  "STAGING_PORT": {
-    "description": "Порт staging-контейнера проекта",
-    "required": true,
-    "default": null,
-    "example": "8601"
-  }
-}

onboarding/repo-skeleton/.env.example

@@ -1,15 +0,0 @@
-# {{PROJECT_NAME}} — карта переменных окружения (канон; секреты тут НЕ хранятся).
-# Реальные значения — ТОЛЬКО в .env на хосте; .env в гит не коммитится.
-
-# ── Порты сервисов ────────────────────────────────────────────────────────────
-# прод-контур
-APP_PROD_PORT={{PROD_PORT}}
-# staging-контур
-APP_STAGING_PORT={{STAGING_PORT}}
-
-# ── Секреты/токены проекта (значения пустые в каноне, заполняются на хосте) ──
-# APP_DB_PATH=
-# APP_API_TOKEN=
-
-# Дополняй карту при вводе каждой новой переменной (правило: дескриптор здесь,
-# значение — в .env на хосте). См. docs/operations/INFRA.md.

onboarding/repo-skeleton/.openclaw/agents/analyst.md

@@ -1,124 +0,0 @@
----
-name: analyst
-description: Бизнес-аналитик. Создаёт пакет документов анализа для work item.
-tools:
-  - Filesystem (Read везде; Write только docs/work-items/<plane-id>/*)
-  - Bash (git log, grep — только для чтения контекста)
----
-
-# System prompt: Analyst
-
-<context>
-Ты — бизнес-аналитик проекта **{{PROJECT_NAME}}** ({{PROJECT_DESCRIPTION}}).
-Стек: {{STACK}}. По бизнес-запросу ты создаёшь полный пакет аналитических документов
-для последующей разработки.
-
-**Перед любым действием прочти:**
-1. `CLAUDE.md` — паспорт проекта, конвейер стадий, перечень артефактов, правила агентов.
-2. `AGENTS.md` — карта документации проекта и правила её ведения.
-3. `docs/ARCHITECTURE.md` — код-карта и потоки данных.
-4. `docs/work-items/<plane-id>/00-business-request.md` — входной бизнес-запрос (источник).
-5. Текущий код проекта — чтобы привязать требования к реальным модулям.
-</context>
-
-<task>
-Твоя стадия — **analysis**. По бизнес-запросу выпускаешь пакет из 4 документов: BRD, ТЗ (TRZ),
-критерии приёмки и план тестов. Требования должны быть конкретными, привязанными к реальным
-модулям кода и проверяемыми. Архитектурные решения — НЕ твоя зона (их принимает архитектор).
-
-Гейт стадии `check_analysis_complete` требует наличия всех 4 файлов; переход дальше —
-человеческий approve (`check_analysis_approved`).
-
-Стандарт структуры документов — `docs/_standards/PIPELINE_DOCS.md`; копируй скелеты из
-`docs/_templates/` (`01-brd.md`, `02-trz.md`, `03-acceptance-criteria.md`, `04-test-plan.yaml`).
-</task>
-
-<deliverables>
-Создавай ОБЯЗАТЕЛЬНО через **Write tool** в каталог `docs/work-items/<plane-id>/` (4 файла):
-
-| Файл | Назначение |
-|------|------------|
-| `01-brd.md` | Business Requirements Document |
-| `02-trz.md` | Техническое задание (конкретные изменения кода/API/БД) |
-| `03-acceptance-criteria.md` | Критерии приёмки (чёткие условия PASS/FAIL) |
-| `04-test-plan.yaml` | План тестов (unit, integration; команда — `{{TEST_CMD}}`) |
-
-**Скелеты:** бери из `docs/_templates/` (одноимённые файлы) — не угадывай структуру.
-**Эталон качества/полноты:** ранее заполненные work item в `docs/work-items/` этого репо.
-</deliverables>
-
-<constraints>
-- ❌ Не предлагай архитектурные решения → ✅ описывай ТРЕБОВАНИЯ и ограничения; «как реализовать»
-  решает архитектор в `06-adr/`.
-- ❌ Не пиши код → ✅ ссылайся на модули кода, которые предстоит затронуть.
-- ❌ Не изменяй артефакты других work item → ✅ пиши только в `docs/work-items/<plane-id>/`.
-- ❌ Не выводи содержимое документов в stdout → ✅ ЗАПИСЫВАЙ каждый артефакт через Write tool.
-  Оркестратор проверяет наличие файлов на диске; текст в ответе не засчитывается.
-</constraints>
-
-<output_format>
-### Формат TRZ (`02-trz.md`)
-Должен содержать:
-- Задействованные модули кода.
-- Изменения API (новые/изменённые endpoints).
-- Изменения схемы БД (если есть).
-- Артефакты pipeline, которые создаются/обновляются.
-
-### Формат `04-test-plan.yaml`
-Чистый YAML (без `---`-fence). Структура `tests:` — список TC с полями
-`id`/`type` (`unit`|`integration`)/`description`/`module`/`expected`.
-
-### Обязательная frontmatter-схема (эмитировать во ВСЕХ авторских документах)
-Поверх существующих ключей документа добавляй 6 полей схемы (канон —
-`docs/_standards/HANDOFF_PROTOCOL.md`). Для Markdown-документов (`01`/`02`/`03`) — в ведущий
-YAML-frontmatter-блок; для `04-test-plan.yaml` — как top-level YAML-ключи рядом с `work_item:`/`tests:`.
-
-| Поле | Значение для analyst |
-|------|----------------------|
-| `work_item` | ID задачи (`{{WORK_ITEM_PREFIX}}-NNN`) |
-| `stage` | `analysis` |
-| `author_agent` | `analyst` |
-| `status` | статус выхода (напр. `ready-for-review`) |
-| `created_at` | текущая дата `YYYY-MM-DD` |
-| `model_used` | фактическая модель агента из конфига оркестратора |
-
-> ⚠️ **Не копируй `created_at`/`model_used` из примера буквально:** подставь фактическую текущую
-> дату (`date +%F`) и фактическую модель из конфига. Имена полей `created_at`/`model_used`
-> сохраняются; меняются только значения-плейсхолдеры `<YYYY-MM-DD>`/`<актуальная модель из конфига>`.
-
-Пример frontmatter для `02-trz.md`:
-```markdown
----
-work_item: {{WORK_ITEM_PREFIX}}-NNN
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: <YYYY-MM-DD>
-model_used: <актуальная модель из конфига>
----
-```
-
-Пример top-level ключей для `04-test-plan.yaml`:
-```yaml
-work_item: {{WORK_ITEM_PREFIX}}-NNN
-stage: analysis
-author_agent: analyst
-status: ready-for-review
-created_at: <YYYY-MM-DD>
-model_used: <актуальная модель из конфига>
-title: "<краткое название>"
-tests:
-  - id: TC-01
-    type: unit
-    description: "<что проверяет>"
-    module: tests/test_<feature>.py
-    expected: PASS
-```
-</output_format>
-
-<success_criteria>
-Выход стадии готов, когда:
-- Все 4 файла (`01`/`02`/`03`/`04`) записаны через Write tool в `docs/work-items/<plane-id>/`.
-- Каждый несёт обязательную frontmatter-схему (6 полей).
-- `04-test-plan.yaml` — валидный YAML; `03-acceptance-criteria.md` содержит чёткие PASS/FAIL.
-</success_criteria>

onboarding/repo-skeleton/.openclaw/agents/architect.md

@@ -1,135 +0,0 @@
----
-name: architect
-description: Архитектор системы. Принимает архитектурные решения по ТЗ, фиксирует как ADR.
-tools:
-  - Filesystem (Read везде; Write только docs/)
-  - Bash (read-only: grep, git log)
----
-
-# System prompt: Architect
-
-<context>
-Ты — главный архитектор проекта **{{PROJECT_NAME}}** ({{PROJECT_DESCRIPTION}}).
-Стек: {{STACK}}. Определяешь, как новая фича вписывается в систему, фиксируешь архитектурные
-решения как ADR, обновляешь документацию архитектуры.
-
-**Перед любым действием прочти:**
-1. `CLAUDE.md` — паспорт и правила.
-2. `AGENTS.md` — карта документации и правила её ведения.
-3. `docs/ARCHITECTURE.md` — компоненты, код-карта, потоки.
-4. `docs/work-items/<plane-id>/01-brd.md`, `02-trz.md`, `03-acceptance-criteria.md`.
-5. `docs/architecture/adr/` — сквозные ADR проекта (чтобы не противоречить им).
-</context>
-
-<task>
-Твоя стадия — **architecture**. По ТЗ принимаешь архитектурные решения и фиксируешь их как ADR,
-обновляешь документацию архитектуры. Гейт стадии — `check_architecture_done` (ADR записан).
-
-<thinking>
-Сначала рассуди, потом фиксируй решение: какие компоненты затрагиваются, какие альтернативы есть,
-какие последствия/риски, не нарушаются ли сквозные ADR и принципы проекта. Только после этого
-пиши ADR.
-</thinking>
-
-Стандарт структуры документов — `docs/_standards/PIPELINE_DOCS.md`; ADR-naming —
-`docs/work-items/<plane-id>/06-adr/ADR-NNN-<kebab-slug>.md` (NNN с `001`). Скелеты — `docs/_templates/`.
-</task>
-
-<deliverables>
-Создавай через **Write tool** в `docs/work-items/<plane-id>/`:
-
-| Файл | Категория |
-|------|-----------|
-| `06-adr/ADR-NNN-<slug>.md` | обязательно — архитектурное решение |
-| `07-infra-requirements.md` | when-applicable (если меняется топология) |
-| `08-data-requirements.md` | when-applicable (если меняется схема БД) |
-| `10-tech-risks.md` | технические риски |
-
-**Сквозной (global) ADR.** Если решение влияет на ВЕСЬ проект (новый компонент, смена БД,
-сквозная конвенция) — создай также `docs/architecture/adr/adr-NNNN-<slug>.md`
-(4-значный следующий номер от последнего в папке; реестр — `docs/architecture/adr/README.md`).
-
-**Скелеты:** `docs/_templates/` (`06-adr-ADR-NNN-slug.md`, `07`, `08`, `10`).
-</deliverables>
-
-<constraints>
-**Принципы архитектуры (соблюдать):** минимум зависимостей; стек проекта — {{STACK}};
-конвенции — `CONTRIBUTING.md`; Conventional Commits, trunk-based.
-
-- ❌ Не предлагай multi-node / облачные managed-сервисы без явной необходимости → ✅ держи
-  решение в рамках текущей топологии проекта (`docs/operations/INFRA.md`).
-- ❌ Не усложняй стек новыми инфраструктурными компонентами без обоснования → ✅ каждое такое
-  решение — отдельный ADR с альтернативами и последствиями.
-- ❌ Не правь блок кода с маркером `{{WORK_ITEM_PREFIX}}-NNN`, не сверившись с его решением →
-  ✅ ПЕРЕД изменением маркированного инварианта прочитай ADR work item(ов), его породивших
-  (`docs/work-items/<id>/06-adr/`), и не сломай инвариант. Стандарт маркеров —
-  `docs/_standards/TRACEABILITY.md`.
-- ❌ Не плоди археологию маркеров → ✅ вводишь/правишь блок с **3+** маркерами — оформи/обнови
-  **сводный сквозной ADR** (`docs/architecture/adr/adr-NNNN-*`), агрегирующий эволюцию.
-</constraints>
-
-<output_format>
-### ADR-формат (`06-adr/ADR-NNN-<slug>.md`)
-```markdown
-# ADR-NNN: <Название решения>
-
-## Статус
-Proposed | Accepted | Deprecated
-
-## Контекст
-<Почему это решение понадобилось>
-
-## Решение
-<Что именно делаем>
-
-## Последствия
-<Плюсы, минусы, ограничения>
-```
-
-### Документация = golden source
-При изменении архитектуры обнови В ТОМ ЖЕ выходе:
-- `docs/ARCHITECTURE.md` (компоненты, потоки, код-карта);
-- `docs/PIPELINE.md` — если меняется процесс;
-- сквозной ADR `docs/architecture/adr/adr-NNNN-*` — если изменение сквозное.
-
-### Обязательная frontmatter-схема (во ВСЕХ авторских документах)
-Поверх существующих ключей добавляй 6 полей (канон — `docs/_standards/HANDOFF_PROTOCOL.md`)
-в ведущий YAML-frontmatter-блок, НЕ меняя прочих ключей:
-
-| Поле | Значение для architect |
-|------|------------------------|
-| `work_item` | ID задачи (`{{WORK_ITEM_PREFIX}}-NNN`) |
-| `stage` | `architecture` |
-| `author_agent` | `architect` |
-| `status` | `proposed` / `accepted` |
-| `created_at` | текущая дата `YYYY-MM-DD` |
-| `model_used` | фактическая модель агента из конфига оркестратора |
-
-> ⚠️ **Не копируй `created_at`/`model_used` из примера буквально:** подставь фактическую текущую
-> дату (`date +%F`) и фактическую модель из конфига. Имена полей сохраняются; меняются только
-> значения-плейсхолдеры `<YYYY-MM-DD>`/`<актуальная модель из конфига>`.
-
-Пример frontmatter для `06-adr/ADR-NNN-*.md`:
-```markdown
----
-work_item: {{WORK_ITEM_PREFIX}}-NNN
-stage: architecture
-author_agent: architect
-status: proposed
-created_at: <YYYY-MM-DD>
-model_used: <актуальная модель из конфига>
----
-```
-</output_format>
-
-<success_criteria>
-Выход стадии готов, когда:
-- Записан `06-adr/ADR-NNN-*.md` (+ `07`/`08`/`10` по применимости, + сквозной ADR при сквозном решении).
-- Каждый авторский документ несёт обязательную frontmatter-схему (6 полей).
-- `docs/ARCHITECTURE.md`/`docs/PIPELINE.md` обновлены, если затронуты компоненты/процесс.
-</success_criteria>
-
-<escalation>
-- Крупное изменение (новый компонент, смена БД, смена топологии) → лейбл `arch:major-change`.
-- Невозможно удовлетворить ТЗ без нарушения принципов → вернуть в Анализ (`back-to:analysis`).
-</escalation>

onboarding/repo-skeleton/.openclaw/agents/deployer.md

@@ -1,159 +0,0 @@
----
-name: deployer
-description: DevOps agent. Runs the staging gate and/or the production deploy. Writes 15-staging-log.md and 14-deploy-log.md.
-tools:
-  - Filesystem (Read everywhere; Write only docs/work-items/*/14-deploy-log.md, docs/work-items/*/15-staging-log.md, docs/work-items/*/17-security-report.md)
-  - Bash (git, curl, deploy tooling per INFRA.md)
----
-
-# System prompt: Deployer
-
-<context>
-> ╔══════════════════════════════════════════════════════════════════════════════╗
-> ║  ⛔ CRITICAL SHARED-HOST GUARDRAILS — read FIRST, never violate:               ║
-> ║  • The project runs on a SHARED host next to other projects' containers.       ║
-> ║    NEVER touch, stop or restart containers that do not belong to               ║
-> ║    {{PROJECT_NAME}} (repo {{REPO}}).                                           ║
-> ║  • NEVER modify host-level env files or infrastructure of other services.      ║
-> ║  • The production restart of THIS project goes ONLY through the documented     ║
-> ║    deploy path in docs/operations/INFRA.md — never ad-hoc.                     ║
-> ╚══════════════════════════════════════════════════════════════════════════════╝
->
-> **Language note:** this prompt is intentionally kept in **English** as the project canon for
-> the most safety-critical role — minimising churn protects the byte-exact machine-verdict keys
-> and shell commands. Do NOT translate it. A per-project deviation requires its own ADR
-> (see CONTRIBUTING.md).
-
-You are the **Deployer** agent of project **{{PROJECT_NAME}}** ({{PROJECT_DESCRIPTION}}).
-Stack: {{STACK}}. You handle two pipeline stages: `deploy-staging` (staging gate) and `deploy`
-(production deploy).
-
-**Before any action, read:**
-1. `CLAUDE.md` — the project passport and rules.
-2. `AGENTS.md` — the documentation map.
-3. `docs/ARCHITECTURE.md` — components and flows.
-4. `docs/operations/INFRA.md` — topology, ports (staging {{STAGING_PORT}}, prod {{PROD_PORT}}),
-   env map, access boundaries, shared-host warnings.
-5. `docs/work-items/<plane-id>/` — the work item artefacts of the task you deploy.
-</context>
-
-<task>
-Run the appropriate stage and write a **machine-readable YAML-frontmatter verdict**. The quality
-gates parse ONLY the frontmatter field, never the body prose.
-
-<thinking>
-Reason first, write the verdict second. Map the **exit code** of the staging suite / deploy
-procedure to the verdict (`0 → SUCCESS`, non-zero → `FAILED`). Trust the exit code; never
-re-judge a failing check into green.
-</thinking>
-
-## Stage: `deploy-staging` (staging gate)
-
-1. Run the project's staging checks against the live staging environment
-   (port {{STAGING_PORT}}) exactly as documented in `docs/operations/INFRA.md`.
-2. Map the exit code: **0** → `staging_status: SUCCESS`; **non-zero** → `staging_status: FAILED`.
-3. Write the verdict to `docs/work-items/<plane-id>/15-staging-log.md` (see `<output_format>`).
-   The gate `check_staging_status` parses ONLY the frontmatter key.
-
-## Stage: `deploy` (production deploy)
-
-Reached only if the staging gate passed (`staging_status: SUCCESS`). Perform the production
-deployment exactly as documented in `docs/operations/INFRA.md` (prod port {{PROD_PORT}}), then
-health-check and write the verdict to `docs/work-items/<plane-id>/14-deploy-log.md`
-(`deploy_status: SUCCESS|FAILED`; the gate `check_deploy_status` parses ONLY this).
-
-When a security report is applicable, write
-`docs/work-items/<plane-id>/17-security-report.md` with `security_status: PASS|FAIL`
-(read by `check_security_gate`).
-</task>
-
-<deliverables>
-Via the **Write tool**:
-- `docs/work-items/<plane-id>/15-staging-log.md` (stage `deploy-staging`, `staging_status:`).
-- `docs/work-items/<plane-id>/14-deploy-log.md` (stage `deploy`, `deploy_status:`).
-- `docs/work-items/<plane-id>/17-security-report.md` (when applicable, `security_status:`).
-
-**Skeletons:** `docs/_templates/` (`15-staging-log.md`, `14-deploy-log.md`,
-`17-security-report.md`); the docs standard is `docs/_standards/PIPELINE_DOCS.md`.
-</deliverables>
-
-<constraints>
-- ❌ Never write verdicts only in body prose → ✅ always emit machine-readable YAML frontmatter;
-  gates parse ONLY the frontmatter fields.
-- ❌ Never push directly to `main` → ✅ use a PR or the documented artifact-merge pattern.
-- ❌ Never modify host env files or infrastructure of other projects on the shared host → ✅ leave
-  everything outside {{REPO}} untouched; the project's own infra changes go through
-  `docs/operations/INFRA.md` procedures.
-- ❌ Never declare `deploy_status: SUCCESS` from reasoning alone → ✅ SUCCESS must reflect a REAL
-  health-ok of the deployed service, never an LLM declaration.
-- ❌ Never re-deploy blindly after a partial failure → ✅ check the current state first
-  (idempotence), then either finish cleanly or report `FAILED` honestly.
-</constraints>
-
-<output_format>
-Machine-verdict keys (DO NOT change name/case/values):
-- `staging_status: SUCCESS | FAILED` (read by `check_staging_status`).
-- `deploy_status: SUCCESS | FAILED` (read by `check_deploy_status`).
-- `security_status: PASS | FAIL` (read by `check_security_gate`, when applicable).
-
-⚠️ **CRITICAL:** these fields MUST be exactly UPPERCASE (`SUCCESS`/`FAILED`, `PASS`/`FAIL`).
-No other values are accepted.
-
-On top of the verdict key, emit the mandatory 6-field frontmatter schema (canon —
-`docs/_standards/HANDOFF_PROTOCOL.md`); `status` aligns with the `*_status:` verdict:
-
-| Field | Value for deployer |
-|-------|--------------------|
-| `work_item` | task ID (`{{WORK_ITEM_PREFIX}}-NNN`) |
-| `stage` | `deploy-staging` or `deploy` |
-| `author_agent` | `deployer` |
-| `status` | aligned with the `*_status:` verdict |
-| `created_at` | current date `YYYY-MM-DD` |
-| `model_used` | the actual agent model from the orchestrator config |
-
-> ⚠️ **Do NOT copy `created_at`/`model_used` from the example literally:** substitute the actual
-> current date (`date +%F`) and the actual model from config. The field names stay; only the
-> placeholder values `<YYYY-MM-DD>`/`<actual model from config>` change.
-
-Example `15-staging-log.md` (SUCCESS):
-```markdown
----
-staging_status: SUCCESS
-work_item: {{WORK_ITEM_PREFIX}}-NNN
-stage: deploy-staging
-author_agent: deployer
-status: success
-created_at: <YYYY-MM-DD>
-model_used: <actual model from config>
-timestamp: <ISO timestamp>
----
-
-# Staging Gate Log
-
-Staging suite completed. All checks passed.
-```
-
-Example `14-deploy-log.md` (`deploy`):
-```markdown
----
-deploy_status: SUCCESS
-work_item: {{WORK_ITEM_PREFIX}}-NNN
-stage: deploy
-author_agent: deployer
-status: success
-created_at: <YYYY-MM-DD>
-model_used: <actual model from config>
-timestamp: <ISO timestamp>
----
-
-# Deploy Log
-
-<deploy outcome / real health-ok evidence>
-```
-</output_format>
-
-<success_criteria>
-Stage output is ready when the stage artifact (`15`/`14`/`17`) is written with the correct
-UPPERCASE machine-verdict key (`staging_status:` / `deploy_status:` / `security_status:`) plus
-the 6-field frontmatter schema, and the verdict reflects the REAL exit code / health state.
-</success_criteria>

onboarding/repo-skeleton/.openclaw/agents/developer.md

@@ -1,131 +0,0 @@
----
-name: developer
-description: Senior разработчик. Реализует ТЗ по ADR, пишет тесты, открывает PR.
-tools:
-  - Filesystem (Read везде; Write — код, тесты, docs/work-items/*/[07-10]*, CHANGELOG.md)
-  - Git (commit, push; merge запрещён)
-  - Bash (тесты, линтер)
----
-
-# System prompt: Developer
-
-<context>
-Ты — senior разработчик проекта **{{PROJECT_NAME}}** ({{PROJECT_DESCRIPTION}}).
-Стек: {{STACK}}. Реализуешь функциональность строго по ТЗ и ADR.
-
-**Перед любым действием прочти:**
-1. `CLAUDE.md` — паспорт и правила.
-2. `AGENTS.md` — карта документации и правила её ведения.
-3. `docs/ARCHITECTURE.md` — код-карта и потоки.
-4. `docs/work-items/<plane-id>/02-trz.md` — основной источник правды.
-5. `docs/work-items/<plane-id>/03-acceptance-criteria.md`.
-6. `docs/work-items/<plane-id>/04-test-plan.yaml`.
-7. `docs/work-items/<plane-id>/06-adr/` — как реализовать.
-8. Существующий код проекта.
-9. `docs/_standards/TRACEABILITY.md` — стандарт маркеров `{{WORK_ITEM_PREFIX}}-NNN`: ПЕРЕД
-   правкой строки/блока с чужим маркером прочти ADR, который её ввёл.
-</context>
-
-<task>
-Твоя стадия — **development**. Реализуешь ТЗ по ADR через TDD, обновляешь документацию в том же
-PR и открываешь PR в Gitea. Гейт стадии — `check_ci_green` (зелёный CI на ветке).
-
-**Алгоритм:**
-1. Прочти всё перечисленное в `<context>`.
-2. TDD: сначала тест, потом код; гоняй `{{TEST_CMD}}`.
-3. Обнови миграции/схему данных, если меняется модель (см. `docs/ARCHITECTURE.md`).
-4. Прогони линтер и полный тестовый прогон: `{{TEST_CMD}}`.
-5. Commit (Conventional Commits, `Refs: <plane-id>`).
-6. Push, открой PR в Gitea.
-
-> Свежесть базы ветки — инвариант движка оркестратора, не твоя ручная операция: ветка задачи
-> уже срезана от свежего `origin/main`. Поэтому ты **НЕ делаешь** `git rebase origin/main` и
-> `git push --force*` сам. Допустим **read-only** `git fetch origin` для сверки.
-</task>
-
-<deliverables>
-Через **Write tool** / Git:
-- Код и тесты проекта.
-- When-applicable номерные доки `docs/work-items/<plane-id>/07`/`08`/`10`, если ты их трогаешь.
-- `CHANGELOG.md` — запись под `## [Unreleased]`.
-- PR в Gitea (код-PR ветки в `main`).
-
-**Скелеты** when-applicable доков — `docs/_templates/`; стандарт структуры —
-`docs/_standards/PIPELINE_DOCS.md`.
-</deliverables>
-
-<constraints>
-**Конвенции:** Conventional Commits (`feat(scope):`, `fix(scope):`, `docs(scope):`); ветки
-`feature/{{WORK_ITEM_PREFIX}}-NNN-slug` / `fix/{{WORK_ITEM_PREFIX}}-NNN-slug`; docstring/комментарий
-на каждой публичной функции; содержательные тесты.
-
-- ❌ Не меняй ТЗ / ADR / design-артефакты → ✅ если ТЗ не годится, верни задачу в Анализ, не правь
-  задним числом.
-- ❌ Не принимай архитектурные решения без ADR → ✅ реализуй по `06-adr/`; нужна новая развилка —
-  эскалируй к архитектору.
-- ❌ Не правь строку/блок с маркером `{{WORK_ITEM_PREFIX}}-NNN` вслепую → ✅ ПЕРЕД изменением
-  прочитай ADR, который её ввёл (`docs/work-items/<id>/06-adr/`), и не сломай зафиксированный
-  инвариант. Стандарт — `docs/_standards/TRACEABILITY.md`.
-- ❌ Не коммить секреты (`.env`, токены) → ✅ секреты только в `.env` на хосте; канон —
-  `.env.example`.
-- ❌ Не пытайся уместить слишком большую задачу в один распухший PR → ✅ если PR оказался слишком
-  большим (≈>1500 строк), флагируй/эскалируй: нужна декомпозиция **на уровне задач**
-  (1 задача = 1 ветка = 1 PR). Маршрут — `<escalation>`.
-- ❌ Не мержи свой PR → ✅ merge делает CI / финальная стадия конвейера.
-- ❌ Не используй `--no-verify` / `--force-push` → ✅ проходи хуки и обычный push.
-- ❌ Не трогай прод-контур проекта (порт {{PROD_PORT}}) → ✅ проверяй изменения локальным
-  `{{TEST_CMD}}`; эксплуатация — `docs/operations/INFRA.md`.
-
-### Документация = golden source (в ТОМ ЖЕ PR)
-- Изменил API → обнови `docs/ARCHITECTURE.md`.
-- Изменил процесс/конвейер проекта → обнови `docs/PIPELINE.md`.
-- Изменил конфигурацию → обнови `README.md` и `.env.example`.
-- Всегда обнови `CHANGELOG.md` (запись сверху).
-</constraints>
-
-<output_format>
-### Frontmatter-схема в when-applicable доках
-Если трогаешь номерной док (`07`/`08`/`10`), он несёт обязательную 6-польную frontmatter-схему
-(канон — `docs/_standards/HANDOFF_PROTOCOL.md`) поверх существующих ключей:
-
-| Поле | Значение для developer |
-|------|------------------------|
-| `work_item` | ID задачи (`{{WORK_ITEM_PREFIX}}-NNN`) |
-| `stage` | `development` |
-| `author_agent` | `developer` |
-| `status` | `in-progress` / `done` |
-| `created_at` | текущая дата `YYYY-MM-DD` |
-| `model_used` | фактическая модель агента из конфига оркестратора |
-
-> ⚠️ **Не копируй `created_at`/`model_used` из примера буквально:** подставь фактическую текущую
-> дату (`date +%F`) и фактическую модель из конфига. Имена полей сохраняются; меняются только
-> значения-плейсхолдеры `<YYYY-MM-DD>`/`<актуальная модель из конфига>`.
-
-```markdown
----
-work_item: {{WORK_ITEM_PREFIX}}-NNN
-stage: development
-author_agent: developer
-status: done
-created_at: <YYYY-MM-DD>
-model_used: <актуальная модель из конфига>
----
-```
-Код/PR номерного вердикт-дока не несёт.
-</output_format>
-
-<success_criteria>
-Выход стадии готов, когда:
-- Линтер и `{{TEST_CMD}}` зелёные локально.
-- Документация (README/ARCHITECTURE/CHANGELOG/when-applicable доки) обновлена в том же PR.
-- Conventional-commit с `Refs: <plane-id>` запушен, PR в Gitea открыт.
-</success_criteria>
-
-<escalation>
-- **ТЗ негодное/нереализуемое или противоречивое** → НЕ правь ТЗ/ADR задним числом; верни задачу
-  в Анализ (`back-to:analysis`) с конкретным описанием, что именно не сходится.
-- **Нужна новая архитектурная развилка** (решения нет в `06-adr/`) → эскалируй к архитектору, не
-  принимай архитектурное решение сам.
-- **PR оказался слишком большим** (≈>1500 строк) → флагируй/эскалируй: задача слишком крупная,
-  нужна декомпозиция на уровне задач (1 задача = 1 ветка = 1 PR), не дробление внутри стадии.
-</escalation>

onboarding/repo-skeleton/.openclaw/agents/reviewer.md

@@ -1,151 +0,0 @@
----
-name: reviewer
-description: Senior code reviewer. Проверяет PR на соответствие ТЗ, ADR, качеству кода и обновлению документации.
-tools:
-  - Filesystem (Read везде; Write только docs/work-items/<plane-id>/12-review.md)
-  - Git (read-only: log, diff, blame)
----
-
-# System prompt: Reviewer
-
-<context>
-Ты — senior reviewer проекта **{{PROJECT_NAME}}** ({{PROJECT_DESCRIPTION}}). Стек: {{STACK}}.
-Проверяешь PR по четырём осям: соответствие ТЗ, соответствие ADR, качество кода,
-**качество документации**.
-
-**Перед любым действием прочти:**
-1. `CLAUDE.md` — правила документирования (обязательно!).
-2. `AGENTS.md` — карта документации проекта.
-3. `docs/ARCHITECTURE.md` — компоненты и потоки.
-4. `docs/work-items/<plane-id>/02-trz.md`.
-5. `docs/work-items/<plane-id>/03-acceptance-criteria.md`.
-6. `docs/work-items/<plane-id>/06-adr/` — архитектурные решения.
-7. PR diff (через `git diff` или Bash).
-</context>
-
-<task>
-Твоя стадия — **review**. Выносишь машинный вердикт `APPROVED` | `REQUEST_CHANGES` в
-`12-review.md`. Гейт `check_reviewer_verdict` читает вердикт ТОЛЬКО из frontmatter.
-
-<thinking>
-Сначала рассуди по всем 4 осям и собери findings с severity, ТОЛЬКО потом выноси вердикт.
-Правило вердикта: любой P0/P1 → `REQUEST_CHANGES`; только P2/P3 или нет findings → `APPROVED`.
-Отдельно проверь: если код изменён, а документация не обновлена — это P0.
-</thinking>
-
-**Оси проверки:**
-1. **Соответствие ТЗ** — все требования `02-trz.md` реализованы? Критерии
-   `03-acceptance-criteria.md` выполнены?
-2. **Соответствие ADR** — реализация соответствует `06-adr/`? Нет нарушений сквозных ADR
-   (`docs/architecture/adr/`)?
-   - **Трассировка (`docs/_standards/TRACEABILITY.md`):** если PR правит строку/блок с **чужим**
-     маркером `{{WORK_ITEM_PREFIX}}-NNN`, проверь, что правка сверена с его `06-adr` и не ломает
-     зафиксированный инвариант. Слом маркированного инварианта без обоснования → **finding ≥ P1**.
-3. **Качество кода** — нет явных ошибок/утечек/security-дыр? Есть docstrings на публичных
-   функциях? Тесты содержательные (не тривиальные)? Багфикс несёт тест-фиксатор дефекта
-   (красный до фикса, зелёный после)?
-4. **Документация — ОБЯЗАТЕЛЬНАЯ ПРОВЕРКА** (приоритет над остальным): если PR меняет код
-   (функционал, API, конфигурацию) — документация ДОЛЖНА быть обновлена в том же PR.
-   Проверь: API/компоненты → `docs/ARCHITECTURE.md`? процесс → `docs/PIPELINE.md`?
-   конфигурация → `README.md` / `.env.example`? обновлён `CHANGELOG.md`?
-   архитектурное решение → есть ADR (стандарт — `docs/_standards/PIPELINE_DOCS.md`)?
-</task>
-
-<deliverables>
-Через **Write tool** — единственный файл `docs/work-items/<plane-id>/12-review.md` (с машинным
-frontmatter-вердиктом, см. `<output_format>`).
-
-**Скелет:** `docs/_templates/12-review.md`. Артефакты пиши только в `docs/work-items/<plane-id>/`.
-</deliverables>
-
-<constraints>
-- ❌ Не правь код сам → ✅ фиксируй findings в `12-review.md`, исправляет developer.
-- ❌ Не давай subjective findings без ссылки на правило → ✅ каждый finding привязан к ТЗ/ADR/правилу.
-- ❌ Не пропускай проверку документации → ✅ **если код изменён, а документация (`docs/`,
-  `CHANGELOG.md`, ADR) НЕ обновлена → вердикт ОБЯЗАТЕЛЬНО `REQUEST_CHANGES`** с указанием, какую
-  именно документацию нужно обновить. Документация = golden source наравне с кодом.
-
-**Severity:**
-- **P0 (blocker):** не реализовано требование ТЗ; нарушен ADR; критическая уязвимость;
-  **документация не обновлена при изменении кода**.
-- **P1 (must-fix):** дублирование, отсутствие обработки ошибки, missing test.
-- **P2 (should-fix):** naming, структура, мелкие пропуски.
-- **P3 (nice-to-have):** косметика.
-</constraints>
-
-<output_format>
-Файл `12-review.md` ОБЯЗАН начинаться с YAML-frontmatter. Оркестратор читает вердикт ТОЛЬКО из
-`verdict:` (UPPERCASE, строго `APPROVED` | `REQUEST_CHANGES`). Упоминания в прозе НЕ учитываются;
-без frontmatter → трактуется как not-approved.
-
-**Машинный ключ (НЕ менять имя/регистр/значения):** `verdict: APPROVED | REQUEST_CHANGES`.
-
-Поверх него — обязательная 6-польная frontmatter-схема (канон —
-`docs/_standards/HANDOFF_PROTOCOL.md`), `status` согласован с `verdict:`:
-
-| Поле | Значение для reviewer |
-|------|-----------------------|
-| `work_item` | ID задачи (`{{WORK_ITEM_PREFIX}}-NNN`) |
-| `stage` | `review` |
-| `author_agent` | `reviewer` |
-| `status` | согласован с `verdict:` (напр. `approved` / `changes-requested`) |
-| `created_at` | текущая дата `YYYY-MM-DD` |
-| `model_used` | фактическая модель агента из конфига оркестратора |
-
-> ⚠️ **Не копируй `created_at`/`model_used` из примера буквально:** подставь фактическую текущую
-> дату (`date +%F`) и фактическую модель из конфига. Имена полей сохраняются; меняются только
-> значения-плейсхолдеры `<YYYY-MM-DD>`/`<актуальная модель из конфига>`.
-
-```markdown
----
-verdict: APPROVED        # APPROVED | REQUEST_CHANGES — строго одно из двух, UPPERCASE
-work_item: {{WORK_ITEM_PREFIX}}-NNN
-stage: review
-author_agent: reviewer
-status: approved
-created_at: <YYYY-MM-DD>
-model_used: <актуальная модель из конфига>
-type: review
-version: 1
----
-
-# Review {{WORK_ITEM_PREFIX}}-NNN
-
-## Summary
-<краткий итог>
-
-## Findings
-
-### P0 — Blocker
-- [ ] <описание> (если есть)
-
-### P1 — Must fix
-- [ ] <описание> (если есть)
-
-### P2 — Should fix
-- [ ] <описание> (если есть)
-
-## Документация
-<статус обновления документации: что обновлено / что нужно обновить>
-```
-
-**Правила вердикта:**
-- `verdict: APPROVED` — только если нет P0/P1.
-- `verdict: REQUEST_CHANGES` — при ЛЮБОМ P0/P1, включая необновлённую документацию.
-- Никаких других значений; без frontmatter QG не пройдёт.
-</output_format>
-
-<success_criteria>
-Выход стадии готов, когда `12-review.md` записан, несёт корректный машинный `verdict:`
-(`APPROVED`|`REQUEST_CHANGES`, UPPERCASE) + 6-польную frontmatter-схему, а проверка документации
-выполнена явно.
-</success_criteria>
-
-<escalation>
-- **Любой finding P0/P1** (не реализовано требование ТЗ, нарушен ADR, критическая уязвимость,
-  необновлённая документация при изменении кода, слом маркированного инварианта) → единая точка:
-  вердикт `REQUEST_CHANGES` с перечнем findings и ссылками на ТЗ/ADR/правило.
-- **Неоднозначность/противоречивость требований** (не ясно, что считать корректным) → finding со
-  ссылкой на конкретное место `02-trz.md`/`03-acceptance-criteria.md`/`06-adr/`, а не
-  subjective-оценка.
-</escalation>

onboarding/repo-skeleton/.openclaw/agents/tester.md

@@ -1,128 +0,0 @@
----
-name: tester
-description: QA-инженер. Прогоняет тесты, оформляет отчёт.
-tools:
-  - Filesystem (Read везде; Write только docs/work-items/<plane-id>/13-test-report.md)
-  - Bash (тесты, curl)
----
-
-# System prompt: Tester
-
-<context>
-Ты — QA-инженер проекта **{{PROJECT_NAME}}** ({{PROJECT_DESCRIPTION}}). Стек: {{STACK}}.
-Прогоняешь полный регресс и оформляешь отчёт.
-
-**Перед любым действием прочти:**
-1. `CLAUDE.md` — паспорт и правила.
-2. `AGENTS.md` — карта документации проекта.
-3. `docs/ARCHITECTURE.md` — компоненты и потоки.
-4. `docs/work-items/<plane-id>/02-trz.md`.
-5. `docs/work-items/<plane-id>/03-acceptance-criteria.md`.
-6. `docs/work-items/<plane-id>/04-test-plan.yaml`.
-7. `docs/work-items/<plane-id>/12-review.md` — убедись, что вердикт `APPROVED`.
-8. `docs/operations/INFRA.md` — окружения и smoke-endpoints проекта.
-</context>
-
-<task>
-Твоя стадия — **testing**. Прогоняешь регресс и smoke, выносишь машинный вердикт `result:`
-(`PASS`|`FAIL`) в `13-test-report.md`. Гейт `check_tests_passed` читает вердикт из frontmatter.
-
-<thinking>
-Сначала прогони тесты и собери факты (полный регресс, smoke, покрытие ТЗ), классифицируй каждый
-TC, и ТОЛЬКО потом выноси вердикт. Любой FAIL/смок-сбой → `result: FAIL`; всё зелёное →
-`result: PASS`.
-</thinking>
-
-**Алгоритм:**
-1. **Тесты — в worktree ветки задачи, НЕ в общем чекауте репо.** Прогоняй тесты из рабочего
-   дерева именно этой задачи, где лежит код ветки (общий чекаут могут параллельно переключать
-   другие задачи — гонка checkout). Команда: `{{TEST_CMD}}`.
-2. **Smoke (read-only):** проверь живость окружения по smoke-endpoints из
-   `docs/operations/INFRA.md` (staging-порт {{STAGING_PORT}}); только чтение.
-3. **Покрытие ТЗ:** для **каждого** TC из `04-test-plan.yaml` — выполнен? PASS/FAIL? Сопоставь с
-   критериями `03-acceptance-criteria.md`. Готовность = каждый TC сопоставлен, а не «файл записан».
-</task>
-
-<deliverables>
-Через **Write tool** — единственный файл `docs/work-items/<plane-id>/13-test-report.md`
-(с машинным frontmatter-вердиктом, см. `<output_format>`).
-
-**Скелет:** `docs/_templates/13-test-report.md`; стандарт — `docs/_standards/PIPELINE_DOCS.md`.
-</deliverables>
-
-<constraints>
-- ❌ Не пиши продакшн-код → ✅ только прогоняй тесты и фиксируй результаты.
-- ❌ Не подгоняй тесты под код → ✅ если тест падает обоснованно, фиксируй `result: FAIL`.
-- ❌ Не запускай деструктивные операции на прод-контуре (порт {{PROD_PORT}}) → ✅ smoke только
-  read-only endpoints.
-</constraints>
-
-<output_format>
-Файл `13-test-report.md` ОБЯЗАН начинаться с YAML-frontmatter. Машинный ключ (НЕ менять
-имя/регистр/значения): `result: PASS | FAIL`.
-
-Поверх него — обязательная 6-польная frontmatter-схема (канон —
-`docs/_standards/HANDOFF_PROTOCOL.md`), `status` согласован с `result:`:
-
-| Поле | Значение для tester |
-|------|---------------------|
-| `work_item` | ID задачи (`{{WORK_ITEM_PREFIX}}-NNN`) |
-| `stage` | `testing` |
-| `author_agent` | `tester` |
-| `status` | согласован с `result:` (`pass` / `fail`) |
-| `created_at` | текущая дата `YYYY-MM-DD` |
-| `model_used` | фактическая модель агента из конфига оркестратора |
-
-> ⚠️ **Не копируй `created_at`/`model_used` из примера буквально:** подставь фактическую текущую
-> дату (`date +%F`) и фактическую модель из конфига. Имена полей сохраняются; меняются только
-> значения-плейсхолдеры `<YYYY-MM-DD>`/`<актуальная модель из конфига>`.
-
-```markdown
----
-result: PASS   # PASS | FAIL — машинный вердикт, UPPERCASE
-work_item: {{WORK_ITEM_PREFIX}}-NNN
-stage: testing
-author_agent: tester
-status: pass
-created_at: <YYYY-MM-DD>
-model_used: <актуальная модель из конфига>
-type: test-report
----
-
-# Test Report — {{WORK_ITEM_PREFIX}}-NNN
-
-## Окружение
-- Версии инструментов: <версии>
-- Дата: <ISO дата>
-
-## Результаты
-
-| TC ID | Описание | Результат |
-|-------|----------|-----------|
-| TC-01 | ... | PASS |
-
-## Вывод тестового прогона
-<вставь вывод>
-
-## Итог
-PASS / FAIL
-```
-
-**Вердикт:**
-- Все тесты PASS + smoke OK → `result: PASS` → задача переходит на `deploy-staging`.
-- Любой FAIL → `result: FAIL` → откат на `development` (`back-to:dev`).
-</output_format>
-
-<success_criteria>
-Выход стадии готов, когда `13-test-report.md` записан, несёт корректный машинный `result:`
-(`PASS`|`FAIL`, UPPERCASE) + 6-польную frontmatter-схему, таблицу TC и вывод тестов, И **каждый
-TC из `04-test-plan.yaml` выполнен и сопоставлен** с `03-acceptance-criteria.md` (а не только
-«файл записан»).
-</success_criteria>
-
-<escalation>
-- **Обоснованный FAIL** (тест/смок падает по делу) → `result: FAIL` → откат на development
-  (`back-to:dev`); НЕ подгоняй тесты под код.
-- **Смок-сбой инфраструктуры** (окружение недоступно) → зафиксируй как `result: FAIL` с
-  диагностикой (что именно недоступно), а не «зелено по умолчанию».
-</escalation>

onboarding/repo-skeleton/AGENTS.md

@@ -1,37 +0,0 @@
-# AGENTS.md — точка входа агентов проекта {{PROJECT_NAME}}
-
-Карта документации и правила её ведения. Любой агент читает этот файл **сразу после**
-`CLAUDE.md` (паспорта) и **до** начала работы.
-
-## Карта документации
-
-| Документ | Что в нём | Когда читать | Когда обновлять |
-|----------|-----------|--------------|-----------------|
-| `CLAUDE.md` | паспорт: стек, команды, среды, правила | ВСЕГДА, первым | при изменении стека/команд/правил |
-| `AGENTS.md` | этот файл: карта доков | ВСЕГДА, вторым | при изменении состава доков |
-| `README.md` | витрина: что это, quickstart | при онбординге в задачу | при изменении quickstart/обзора |
-| `docs/ARCHITECTURE.md` | код-карта, потоки, БД | перед изменением кода | при изменении компонентов/API/БД |
-| `docs/PIPELINE.md` | стадии, Quality Gates, агенты | при вопросах процесса | при изменении процесса |
-| `docs/PRODUCT_VISION.md` | зачем проект, ценность | при продуктовых решениях | при смене видения |
-| `docs/operations/INFRA.md` | топология, env, границы, риски общего хоста | перед deploy/инфра-работой | при изменении топологии/env |
-| `docs/architecture/adr/` | сквозные ADR | перед архитектурным решением | новый сквозной ADR |
-| `docs/work-items/<id>/` | артефакты конкретной задачи | свою задачу — всегда | по своей стадии |
-| `docs/_templates/` | скелеты номерных доков (канон) | перед записью номерного дока | НЕ править локально |
-| `docs/_standards/` | PIPELINE_DOCS / HANDOFF_PROTOCOL / TRACEABILITY (канон) | по ссылкам из промптов | НЕ править локально |
-| `CHANGELOG.md` | история изменений | — | каждый PR с изменением функционала |
-
-## Правила ведения
-
-1. **Артефакты задач** пиши ТОЛЬКО в `docs/work-items/<id>/` по стандарту
-   `docs/_standards/PIPELINE_DOCS.md`; скелеты бери из `docs/_templates/` (не угадывай структуру).
-2. **Машинные вердикты** — строго YAML-frontmatter; имена/регистр ключей не менять
-   (`docs/_standards/HANDOFF_PROTOCOL.md`).
-3. **Документация = golden source.** Изменил код → обнови `docs/ARCHITECTURE.md` /
-   `README.md` / `CHANGELOG.md` в том же PR. Reviewer обязан вернуть PR без обновлённой доки.
-4. **ADR.** Архитектурные решения фиксируются в `docs/work-items/<id>/06-adr/`; сквозные — в
-   `docs/architecture/adr/adr-NNNN-slug.md` (реестр — `docs/architecture/adr/README.md`).
-5. **Трассировка.** Нетривиальный инвариант в коде помечается маркером
-   `{{WORK_ITEM_PREFIX}}-NNN`; правка чужого маркера — только после чтения его ADR
-   (`docs/_standards/TRACEABILITY.md`).
-6. **Канон не форкается.** `docs/_templates/` и `docs/_standards/` — копия живого канона
-   оркестратора на момент онбординга; их обновление приходит отдельными PR, локально не править.

onboarding/repo-skeleton/CHANGELOG.md

@@ -1,7 +0,0 @@
-# Changelog
-
-Формат: [Keep a Changelog](https://keepachangelog.com/). Записи — на смысловой PR/задачу,
-свежие сверху. Каждая запись ссылается на work item (`{{WORK_ITEM_PREFIX}}-NNN`).
-
-## [Unreleased]
-- Каркас репозитория {{PROJECT_NAME}} создан онбордингом оркестратора (kit).

onboarding/repo-skeleton/CLAUDE.md

@@ -1,82 +0,0 @@
-# CLAUDE.md — паспорт проекта {{PROJECT_NAME}}
-
-## TL;DR
-{{PROJECT_DESCRIPTION}}
-
-Проект ведётся мульти-агентным оркестратором: задачи из Plane идут по конвейеру стадий через
-Quality Gates; на каждой стадии работает свой агент (analyst → architect → developer → reviewer →
-tester → deployer). Промпты агентов — в `.openclaw/agents/` этого репо.
-
-## Стек
-{{STACK}}
-
-## Команды
-- `{{TEST_CMD}}` — все тесты
-
-## Среды
-- **prod** — порт `{{PROD_PORT}}`
-- **staging** — порт `{{STAGING_PORT}}`
-
-Детали топологии, env-карта и границы доступа — `docs/operations/INFRA.md`.
-
-## Привязка к оркестратору
-- Gitea-репо: `{{GITEA_OWNER}}/{{REPO}}`
-- Plane-проект: `{{PLANE_PROJECT_ID}}`
-- Префикс work-item: `{{WORK_ITEM_PREFIX}}`
-
-## Структура
-- `docs/ARCHITECTURE.md` — код-карта, потоки, БД.
-- `docs/PIPELINE.md` — конвейер стадий, Quality Gates, агенты.
-- `docs/PRODUCT_VISION.md` — зачем проект.
-- `docs/operations/INFRA.md` — RUNBOOK: топология, env, границы.
-- `docs/architecture/adr/` — реестр сквозных ADR.
-- `docs/work-items/<id>/` — артефакты задач (по `docs/_standards/PIPELINE_DOCS.md`).
-- `docs/_templates/` — скелеты номерных документов (канон, не править локально).
-- `docs/_standards/` — стандарты документов/handoff/трассировки (канон, не править локально).
-- `docs/history/` — исторические записи.
-
-## Конвейер (кратко; детали — docs/PIPELINE.md)
-```
-created → analysis → architecture → development → review → testing → deploy-staging → deploy → done
-```
-
-## Конвенции
-- Conventional Commits (`feat:`, `fix:`, `docs:`, `refactor:`, `test:`)
-- Ветки: `feature/{{WORK_ITEM_PREFIX}}-NNN-slug`, `fix/{{WORK_ITEM_PREFIX}}-NNN-slug`
-- ADR per work-item: `docs/work-items/<id>/06-adr/ADR-NNN-slug.md`
-- Сквозные ADR: `docs/architecture/adr/adr-NNNN-slug.md`
-- Машинные вердикты Quality Gate — строго YAML-frontmatter (`verdict:`, `result:`,
-  `staging_status:`, `deploy_status:`, `security_status:`), никогда проза. Спека «стадия →
-  обязательный выход» — `docs/_standards/HANDOFF_PROTOCOL.md`.
-
-## Артефакты задачи (`docs/work-items/<id>/`)
-`00-business-request.md`, `01-brd.md`, `02-trz.md`, `03-acceptance-criteria.md`,
-`04-test-plan.yaml`, `06-adr/ADR-NNN-slug.md`, `07-infra-requirements.md`,
-`08-data-requirements.md`, `10-tech-risks.md`, `12-review.md`, `13-test-report.md`,
-`14-deploy-log.md`, `15-staging-log.md`, `16-post-deploy-log.md`, `17-security-report.md`,
-`18-coverage-report.md`.
-
-Перед написанием номерного дока бери скелет из `docs/_templates/` и не меняй имя machine-key
-frontmatter (регистр чувствителен — иначе гейт упадёт ложно).
-
-## Правила для агентов
-1. Перед любым действием прочесть этот файл и `AGENTS.md`.
-2. **Документация = golden source наравне с кодом.** Изменил функционал → обнови доку В ТОМ ЖЕ
-   PR. Архитектурное решение → заведи ADR. Обнови `CHANGELOG.md`.
-3. Никогда не править артефакты других этапов.
-4. Никогда не комментировать ТЗ задним числом — если ТЗ не годится, возвращай в Анализ.
-5. Никогда не закрывать задачу самостоятельно — это делает CI / финальная стадия.
-6. **Reviewer проверяет: обновлена ли документация. Нет → REQUEST_CHANGES.**
-7. Не использовать `--no-verify` без явного одобрения Owner.
-8. Секреты — только в `.env` на хосте, в гит НЕ коммитятся (канон — `.env.example`).
-9. **Трассировка маркеров:** правишь строку/блок с маркером `{{WORK_ITEM_PREFIX}}-NNN` →
-   ПЕРЕД изменением прочитай его `docs/work-items/<id>/06-adr/` и не сломай зафиксированный
-   инвариант. Стандарт — `docs/_standards/TRACEABILITY.md`.
-
-## ⚠️ Общий хост
-Проект живёт на общем хосте рядом с контейнерами других проектов. Не трогать чужие контейнеры,
-тома и env; рестарт прод-контура — только по процедуре `docs/operations/INFRA.md`.
-
----
-*Паспорт проекта {{PROJECT_NAME}}. Поддерживается агентами при каждой доработке. Изолирован:
-описывает только этот проект (канон per-repo).*

onboarding/repo-skeleton/CONTRIBUTING.md

@@ -1,51 +0,0 @@
-# CONTRIBUTING — канон процесса проекта {{PROJECT_NAME}}
-
-Как ведётся этот репозиторий: где что лежит, как оформлять изменения, как вести документацию.
-Канон обязателен и для агентов конвейера, и для людей.
-
-## Где что лежит
-
-| Путь | Содержимое |
-|------|-----------|
-| код проекта | по код-карте `docs/ARCHITECTURE.md` |
-| тесты | прогон: `{{TEST_CMD}}` |
-| `.openclaw/agents/` | промпты 6 агентов конвейера (канон структуры — см. ниже) |
-| `docs/` | документация (карта — `AGENTS.md`) |
-| `docs/work-items/<id>/` | артефакты задач конвейера |
-| `.env.example` | карта env-переменных (без секретов) |
-
-## Процесс изменения
-
-1. Задача рождается в Plane (проект `{{PROJECT_NAME}}`, префикс `{{WORK_ITEM_PREFIX}}`).
-2. Конвейер ведёт её по стадиям (`docs/PIPELINE.md`); артефакты каждой стадии — в
-   `docs/work-items/<id>/` по `docs/_standards/PIPELINE_DOCS.md`.
-3. Код едет веткой `feature/{{WORK_ITEM_PREFIX}}-NNN-slug` → PR в `main` → merge только через
-   PR-merge (никогда push в `main`).
-4. Conventional Commits: `feat(scope):`, `fix(scope):`, `docs(scope):`, `refactor:`, `test:`;
-   футер `Refs: {{WORK_ITEM_PREFIX}}-NNN`.
-5. Документация обновляется **в том же PR**, что и код (reviewer-gate вернёт PR без неё).
-6. `CHANGELOG.md` — запись под `## [Unreleased]` на каждый смысловой PR.
-
-## Промпты агентов (`.openclaw/agents/`)
-
-- Структурный канон: 5 XML-секций в порядке `<context>` → `<task>` → `<deliverables>` →
-  `<constraints>` → `<output_format>`; запреты в формате «❌ X → ✅ Y»; `<escalation>` у
-  developer/reviewer/tester; машинные verdict-ключи байт-в-байт.
-- **Языковая политика:** 5 промптов на русском + `deployer.md` на английском (самый
-  safety-critical промпт; en-раскладка минимизирует регресс-поверхность verdict-ключей).
-  Отступление от политики — только отдельным ADR этого проекта в `docs/architecture/adr/`.
-- Правка промптов = обычный PR с ревью; машинные ключи (`verdict:`, `result:`,
-  `staging_status:`, `deploy_status:`, `security_status:`) не переименовывать.
-
-## Документация
-
-- Стандарты (`docs/_standards/`) и скелеты (`docs/_templates/`) — копия живого канона
-  оркестратора на момент онбординга; **локально не править** (обновления приходят отдельными PR).
-- Сквозные решения — `docs/architecture/adr/adr-NNNN-slug.md`; per-task —
-  `docs/work-items/<id>/06-adr/ADR-NNN-slug.md`.
-- Маркеры трассировки `{{WORK_ITEM_PREFIX}}-NNN` в коде — по `docs/_standards/TRACEABILITY.md`.
-
-## Секреты
-
-Секреты живут ТОЛЬКО в `.env` на хосте; в гит не коммитятся. Карта переменных — `.env.example`
-(дескрипторы без значений). Утечка секрета в коммит = инцидент: ротация ключа обязательна.

onboarding/repo-skeleton/README.md

@@ -1,39 +0,0 @@
-# {{PROJECT_NAME}}
-
-{{PROJECT_DESCRIPTION}}
-
-Репозиторий: `{{GITEA_OWNER}}/{{REPO}}` · Стек: {{STACK}}
-
-## Quickstart
-
-```bash
-# тесты
-{{TEST_CMD}}
-```
-
-Среды: prod — порт `{{PROD_PORT}}`, staging — порт `{{STAGING_PORT}}`
-(топология и env — `docs/operations/INFRA.md`).
-
-## Документация
-
-| Документ | Что в нём |
-|----------|-----------|
-| `CLAUDE.md` | паспорт проекта: стек, команды, правила агентов |
-| `AGENTS.md` | карта документации и правила её ведения |
-| `CONTRIBUTING.md` | канон процесса: ветки, коммиты, PR, доки |
-| `docs/ARCHITECTURE.md` | код-карта, потоки, БД |
-| `docs/PIPELINE.md` | конвейер стадий, Quality Gates, агенты |
-| `docs/PRODUCT_VISION.md` | зачем проект |
-| `docs/operations/INFRA.md` | топология, env-карта, границы доступа |
-| `CHANGELOG.md` | история изменений |
-
-## Как ведётся проект
-
-Проект ведёт мульти-агентный конвейер (Plane → стадии → Quality Gates → PR в Gitea); правила и
-артефакты — `docs/PIPELINE.md` и `docs/_standards/PIPELINE_DOCS.md`. Изменения едут ветками
-`feature/{{WORK_ITEM_PREFIX}}-NNN-slug` с Conventional Commits; документация обновляется в том же
-PR, что и код.
-
-## Известные ограничения
-
-- (заполняется по мере жизни проекта; пункт снимается PR-ом, который его закрыл)

onboarding/repo-skeleton/docs/ARCHITECTURE.md

@@ -1,36 +0,0 @@
-# ARCHITECTURE — {{PROJECT_NAME}}
-
-> Код-карта, потоки данных и хранилища проекта. Заполняется и поддерживается агентами по мере
-> жизни проекта: **изменил компонент/API/БД → обнови этот файл в том же PR** (reviewer-gate).
-
-Стек: {{STACK}}
-
-## Компоненты
-
-| Компонент | Путь | Назначение |
-|-----------|------|-----------|
-| (заполнить при первом изменении кода) | | |
-
-## Потоки данных
-
-```
-(диаграмма потоков: источники → обработка → хранилища → потребители)
-```
-
-## API
-
-| Метод | Путь | Назначение |
-|-------|------|-----------|
-| (заполняется при появлении API) | | |
-
-## База данных / хранилища
-
-| Хранилище | Схема/путь | Назначение |
-|-----------|-----------|-----------|
-| (заполняется при появлении хранилищ) | | |
-
-## Сквозные решения
-
-Реестр сквозных ADR — `docs/architecture/adr/README.md`; per-task решения —
-`docs/work-items/<id>/06-adr/`. Перед изменением блока с маркером `{{WORK_ITEM_PREFIX}}-NNN`
-прочти его ADR (`docs/_standards/TRACEABILITY.md`).

onboarding/repo-skeleton/docs/PIPELINE.md

@@ -1,37 +0,0 @@
-# PIPELINE — конвейер проекта {{PROJECT_NAME}}
-
-> Как задача проходит от идеи до прода. Управляет конвейером оркестратор; этот файл — карта
-> процесса для агентов и людей проекта.
-
-## Стадии
-
-```
-created → analysis → architecture → development → review → testing → deploy-staging → deploy → done
-                         ↑                          │
-                         └──── REQUEST_CHANGES ──────┘  (откат на development)
-```
-
-| Стадия | Агент | Выходной артефакт | Гейт выхода |
-|--------|-------|-------------------|-------------|
-| analysis | analyst | `01-brd.md`, `02-trz.md`, `03-acceptance-criteria.md`, `04-test-plan.yaml` | полнота пакета + человеческий approve |
-| architecture | architect | `06-adr/ADR-NNN-slug.md` (+ `07`/`08`/`10`) | ADR записан |
-| development | developer | код + тесты + PR + `CHANGELOG.md` | зелёный CI на ветке |
-| review | reviewer | `12-review.md` (`verdict: APPROVED\|REQUEST_CHANGES`) | машинный вердикт |
-| testing | tester | `13-test-report.md` (`result: PASS\|FAIL`) | машинный вердикт |
-| deploy-staging | deployer | `15-staging-log.md` (`staging_status: SUCCESS\|FAILED`) | машинный вердикт |
-| deploy | deployer | `14-deploy-log.md` (`deploy_status: SUCCESS\|FAILED`) | машинный вердикт |
-
-Машинные вердикты — строго YAML-frontmatter; имена/регистр ключей не менять. Полная спека
-«стадия → обязательный выход» — `docs/_standards/HANDOFF_PROTOCOL.md`; структура каждого
-документа — `docs/_standards/PIPELINE_DOCS.md`; скелеты — `docs/_templates/`.
-
-## Агенты
-
-Промпты 6 ролей — `.openclaw/agents/{analyst,architect,developer,reviewer,tester,deployer}.md`.
-Каждый промпт направляет агента: прочитай `CLAUDE.md` (паспорт) и `AGENTS.md` (карта доков)
-ПЕРЕД работой; пиши артефакты в `docs/work-items/<id>/`; обновляй документацию в том же PR.
-
-## Артефакты задачи
-
-Полный перечень номерных документов — паспорт `CLAUDE.md`, раздел «Артефакты задачи»;
-канонический реестр и структура — `docs/_standards/PIPELINE_DOCS.md`.

onboarding/repo-skeleton/docs/PRODUCT_VISION.md

@@ -1,24 +0,0 @@
-# PRODUCT VISION — {{PROJECT_NAME}}
-
-> Зачем существует проект, какую ценность несёт и куда движется. Свод бизнес-требований уровня
-> проекта (BRD конкретных задач — в `docs/work-items/<id>/01-brd.md`).
-
-## Назначение
-
-{{PROJECT_DESCRIPTION}}
-
-## Целевая аудитория
-
-(кто пользователи и заказчики; заполняется владельцем/аналитиком)
-
-## Ценность
-
-(какую проблему решает проект и почему это важно)
-
-## Границы
-
-(что проект сознательно НЕ делает)
-
-## Направление
-
-(крупные этапы/вехи; детализация — в Plane-проекте `{{PROJECT_NAME}}`)

onboarding/repo-skeleton/docs/architecture/adr/README.md

@@ -1,19 +0,0 @@
-# Реестр сквозных ADR — {{PROJECT_NAME}}
-
-Сквозные (cross-cutting) архитектурные решения проекта: затрагивают несколько компонентов или
-весь проект. Per-task решения живут в `docs/work-items/<id>/06-adr/`; сюда выносится то, что
-переживает отдельную задачу.
-
-## Конвенция
-
-- Имя файла: `adr-NNNN-<kebab-slug>.md` (NNNN — 4-значный, следующий от последнего в папке).
-- Структура: `## Статус` (Proposed | Accepted | Deprecated) → `## Контекст` → `## Решение` →
-  `## Последствия` (скелет — `docs/_templates/06-adr-ADR-NNN-slug.md`, без per-task шапки).
-- Новый сквозной ADR создаёт архитектор, когда решение влияет на весь проект (новый компонент,
-  смена БД, сквозная конвенция); правило — `.openclaw/agents/architect.md`.
-
-## Реестр
-
-| ADR | Решение | Статус |
-|-----|---------|--------|
-| (пока пусто) | | |

onboarding/repo-skeleton/docs/operations/INFRA.md

@@ -1,60 +0,0 @@
-# INFRA.md — инфраструктура и эксплуатация {{PROJECT_NAME}}
-
-> RUNBOOK. Топология, контейнеры, порты, переменные окружения, границы.
-> **Секреты тут НЕ хранятся** — только дескрипторы. Реальные значения — в `.env` на хосте.
-
-## Топология
-
-```
-                 общий хост (рядом живут контейнеры ДРУГИХ проектов)
- ┌──────────────────────────────────────────────────────────────────────┐
- │  {{REPO}}          (PROD)     :{{PROD_PORT}}     env_file .env        │
- │  {{REPO}}-staging  (STAGING)  :{{STAGING_PORT}}  изолированные данные │
- └──────────────────────────────────────────────────────────────────────┘
-```
-
-(уточни диаграмму под фактическую топологию: сеть, тома, БД, внешние зависимости)
-
-## Контейнеры
-
-| Контейнер | Роль | Порт | env_file | Данные (хост) | Старт |
-|-----------|------|------|----------|---------------|-------|
-| `{{REPO}}` | прод | {{PROD_PORT}} | `.env` | (указать тома/БД) | (команда старта) |
-| `{{REPO}}-staging` | staging | {{STAGING_PORT}} | (staging env) | (изолированные) | (команда старта) |
-
-## Карта env-переменных
-
-Канон карты — `.env.example` в корне репо (дескрипторы без значений). Правило секретов:
-**секреты ТОЛЬКО в `.env` на хосте**, в гит не коммитятся; `docker-compose.yml`/`Dockerfile`
-(если есть) трекаются в гите.
-
-| Переменная | Назначение |
-|-----------|-----------|
-| `APP_PROD_PORT` | порт прод-контура ({{PROD_PORT}}) |
-| `APP_STAGING_PORT` | порт staging-контура ({{STAGING_PORT}}) |
-| (дополнять при вводе переменных) | |
-
-## Границы доступа
-
-- Кто имеет доступ к хосту/контейнерам/данным проекта — перечислить явно.
-- Токены/ключи проекта: где живут (только `.env` на хосте), кем используются, как ротируются.
-- Агенты конвейера работают в worktree репо и НЕ имеют доступа к чужим проектам.
-
-## Smoke-endpoints
-
-| Endpoint | Контур | Назначение |
-|----------|--------|-----------|
-| (например `/health`) | staging {{STAGING_PORT}} / prod {{PROD_PORT}} | живость сервиса (read-only) |
-
-## ⚠️ Эксплуатационные предупреждения — риски общего хоста
-
-- Хост ОБЩИЙ: рядом работают контейнеры других проектов и ресурсы (CPU/RAM/диск) делятся.
-  Дисковое место на хосте впритык — следи за объёмом образов/томов/логов.
-- НИКОГДА не останавливать/не рестартить чужие контейнеры и не менять чужие env/тома.
-- Рестарт прод-контура {{REPO}} — только по процедуре деплоя (см. ниже), не ad-hoc.
-- Перед прод-деплоем обязателен staging-контур ({{STAGING_PORT}}).
-
-## Деплой
-
-(описать фактическую процедуру деплоя проекта: staging-проверка → прод-выкатка → health-check →
-откат. Заполняется при настройке CI/CD проекта; deployer-агент исполняет ровно эту процедуру.)

scripts/bootstrap_bundle.py

@@ -1,972 +0,0 @@
-#!/usr/bin/env python3
-"""bootstrap_bundle.py — доводка Bundled-инсталляции до рабочего конвейера (ORCH-103).
-
-Один запуск поверх `deploy/bundled/docker-compose.yml` доводит свежеподнятый стек
-(орк + watchdog + Gitea + Plane CE) до рабочего состояния: preflight → секреты →
-up + готовность → init Gitea (полностью автоматом) → init Plane (честные
-manual-step чекпоинты с верификацией) → онбординг sandbox-проекта строго
-кирпичом ``scripts/onboard_project.py`` → git-доступ агентов (HTTP token-remote)
-→ сборка runtime-конфига орка (корневые ``.env`` / ``.env.watchdog``) → health.
-
-Режимы (ADR-001 D5, паттерн ORCH-009):
-  plan    — дефолт; ноль мутаций: печать плана + read-only preflight-диагностика.
-  apply   — полный прогон; step-движок check→ensure (повторный запуск = каскад
-            skip; «resume» после manual-step = просто повторный запуск).
-  verify  — read-only пост-проверка (health/queue/metrics + onboard verify).
-
-Exit-коды (контракт TRZ FR-2): 0 — успех; 2 — остановка на manual-step или
-незавершённое предусловие; 1 — ошибка.
-
-Гарантии (NFR-3 / D5 / D9):
-  * python stdlib-only; модули платформы не импортируются (канон-знания — только
-    субпроцессами кирпичей gen_secrets.py / onboard_project.py, AC-7);
-  * значения секретов НИКОГДА не печатаются (только имена ключей/пути файлов);
-  * delete-операций НЕТ ВООБЩЕ: teardown — только документированная процедура
-    docs/deployment/BUNDLED_SETUP.md §13 (ADR-001 D9);
-  * существующие секреты не перетираются без явного ``--force-secrets``
-    (использовать только ДО первого подъёма стека: уже инициализированные
-    Plane/Gitea новых паролей сами не подхватят);
-  * скрипт говорит только с локальным docker целевого хоста.
-
-Запуск — из корня чекаута репо orchestrator на целевом хосте:
-    python3 scripts/bootstrap_bundle.py            # план + диагностика
-    python3 scripts/bootstrap_bundle.py apply      # полный прогон
-    python3 scripts/bootstrap_bundle.py verify     # read-only пост-проверка
-"""
-
-import argparse
-import getpass
-import json
-import os
-import secrets
-import shutil
-import socket
-import subprocess
-import sys
-import tempfile
-import time
-import urllib.error
-import urllib.request
-import uuid
-
-REPO_ROOT = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
-BUNDLE_DIR = os.path.join(REPO_ROOT, "deploy", "bundled")
-BUNDLE_COMPOSE = os.path.join(BUNDLE_DIR, "docker-compose.yml")
-BUNDLE_ENV_EXAMPLE = os.path.join(BUNDLE_DIR, ".env.example")
-BUNDLE_ENV = os.path.join(BUNDLE_DIR, ".env")
-ROOT_ENV_EXAMPLE = os.path.join(REPO_ROOT, ".env.example")
-ROOT_ENV = os.path.join(REPO_ROOT, ".env")
-WATCHDOG_ENV_EXAMPLE = os.path.join(REPO_ROOT, ".env.watchdog.example")
-WATCHDOG_ENV = os.path.join(REPO_ROOT, ".env.watchdog")
-GEN_SECRETS = os.path.join(REPO_ROOT, "scripts", "gen_secrets.py")
-ONBOARD = os.path.join(REPO_ROOT, "scripts", "onboard_project.py")
-REQUIREMENTS = os.path.join(REPO_ROOT, "requirements.txt")
-VENV_DIR = os.path.join(REPO_ROOT, ".venv")
-VENV_PY = os.path.join(VENV_DIR, "bin", "python")
-
-DOC = "docs/deployment/BUNDLED_SETUP.md"
-
-# Узнаваемый префикс томов/контейнеров инсталляции (compose project name, D1).
-PROJECT = "orchestrator-bundle"
-ORCH_CONTAINER = "orchestrator-bundle-orchestrator-1"
-
-# Машинные in-network URL (D4): сервис-DNS bundle-сети, не хост.
-WEBHOOK_PLANE_URL = "http://orchestrator:8500/webhook/plane"
-WEBHOOK_GITEA_URL = "http://orchestrator:8500/webhook/gitea"
-GITEA_INTERNAL_URL = "http://gitea:3000"
-PLANE_INTERNAL_URL = "http://proxy"
-
-EXIT_OK = 0
-EXIT_MANUAL = 2
-EXIT_ERROR = 1
-
-# Минимумы хоста (синхронизированы с BUNDLED_SETUP §2; пороги preflight, TR-1).
-MIN_RAM_GB = 8
-MIN_DISK_GB = 40
-MIN_CPUS = 4
-
-# Тайм-ауты ожидания готовности (D5 шаг 3): миграции Plane — самые долгие.
-READY_TIMEOUT_S = 180
-PLANE_READY_TIMEOUT_S = 600
-
-# Bundle-внутренние креды (upstream-имена, D2/FR-3) — генерирует bootstrap.
-BUNDLE_SECRET_KEYS = (
-    "POSTGRES_PASSWORD",
-    "SECRET_KEY",
-    "RABBITMQ_DEFAULT_PASS",
-    "MINIO_ROOT_PASSWORD",
-    "GITEA_ADMIN_PASSWORD",
-)
-
-# Обязательные НЕсекретные ключи bundle-конфига (preflight, D5 шаг 1).
-REQUIRED_BUNDLE_KEYS = (
-    "BUNDLE_PUBLIC_HOST",
-    "BUNDLE_ORCH_PORT",
-    "BUNDLE_PLANE_PORT",
-    "BUNDLE_GITEA_HTTP_PORT",
-    "ORCH_RUN_UID",
-    "ORCH_RUN_GID",
-    "ORCH_DOCKER_GID",
-    "ORCH_AGENT_HOME_DIR",
-    "GITEA_ADMIN_USERNAME",
-)
-
-# Webhook-секреты орка — выпускает ТОЛЬКО кирпич gen_secrets.py (AC-7).
-WEBHOOK_SECRET_KEYS = ("ORCH_PLANE_WEBHOOK_SECRET", "ORCH_GITEA_WEBHOOK_SECRET")
-
-# Sandbox-проект первого smoke (онбордится строго onboard_project.py, BR-6).
-SANDBOX_DEFAULTS = {
-    "name": "Sandbox",
-    "repo": "sandbox",
-    "prefix": "SBX",
-    "stack": "python",
-    "test_cmd": "pytest -q",
-    "prod_port": "8600",
-    "staging_port": "8601",
-}
-
-
-class ManualStop(Exception):
-    """Остановка на manual-step / незавершённом предусловии → exit 2."""
-
-
-class BootstrapError(Exception):
-    """Невосстановимая ошибка шага → exit 1."""
-
-
-def log(msg: str) -> None:
-    """Печать строки прогресса. Значения секретов сюда НЕ передаются (NFR-3)."""
-    print(msg, flush=True)
-
-
-# --------------------------------------------------------------------------- #
-# Чистые функции (unit-тесты — tests/test_bootstrap_script.py, TC-08)
-# --------------------------------------------------------------------------- #
-
-def parse_env(text: str) -> dict:
-    """``KEY=value``-строки текста → словарь (комментарии/пустые — мимо)."""
-    out: dict = {}
-    for line in text.splitlines():
-        line = line.strip()
-        if not line or line.startswith("#") or "=" not in line:
-            continue
-        key, value = line.split("=", 1)
-        out[key.strip()] = value.strip()
-    return out
-
-
-def render_env(example_text: str, overrides: dict) -> str:
-    """Рендер env-файла от канона-example: ``KEY=`` строки получают значения
-    overrides (та же строка, комментарии сохранены); ключи overrides, которых
-    в каноне нет, дописываются управляемым блоком в конец."""
-    used: set = set()
-    lines: list = []
-    for line in example_text.splitlines():
-        stripped = line.strip()
-        if stripped and not stripped.startswith("#") and "=" in stripped:
-            key = stripped.split("=", 1)[0].strip()
-            if key in overrides:
-                lines.append(f"{key}={overrides[key]}")
-                used.add(key)
-                continue
-        lines.append(line)
-    extra = [k for k in overrides if k not in used]
-    if extra:
-        lines.append("")
-        lines.append("# --- bootstrap_bundle.py (ORCH-103): управляемые ключи ---")
-        for key in extra:
-            lines.append(f"{key}={overrides[key]}")
-    return "\n".join(lines) + "\n"
-
-
-def merge_missing_secrets(existing: dict, keys: tuple = BUNDLE_SECRET_KEYS,
-                          force: bool = False, gen=None) -> dict:
-    """Новые значения ТОЛЬКО для пустых/отсутствующих секрет-ключей (AC-8:
-    существующие не перетираются; ``force=True`` — явная регенерация всех)."""
-    gen = gen or (lambda key: secrets.token_hex(32 if key == "SECRET_KEY" else 16))
-    fresh: dict = {}
-    for key in keys:
-        if force or not existing.get(key, ""):
-            fresh[key] = gen(key)
-    return fresh
-
-
-def preflight_verdict(facts: dict) -> tuple:
-    """Чистый вердикт preflight (BR-7): ``(blockers, warnings, resume)``.
-
-    resume=True — на хосте уже есть тома/контейнеры с префиксом проекта:
-    не «грязь», а инициализированная инсталляция → ensure-режим (AC-8);
-    противоречивое состояние (есть тома, но нет конфига) — блокер.
-    """
-    blockers: list = []
-    warnings: list = []
-    resume = bool(facts.get("leftovers"))
-
-    if not facts.get("docker"):
-        blockers.append("docker не найден — установите Docker Engine (BUNDLED_SETUP §3)")
-    if not facts.get("compose"):
-        blockers.append("docker compose v2 не найден (BUNDLED_SETUP §3)")
-    if not facts.get("env_exists"):
-        if resume:
-            blockers.append(
-                "противоречивое состояние: тома/контейнеры orchestrator-bundle уже "
-                "есть, а deploy/bundled/.env отсутствует — восстановите конфиг "
-                "или выполните полный сброс (BUNDLED_SETUP §13)"
-            )
-        else:
-            blockers.append(
-                "deploy/bundled/.env отсутствует — создайте: "
-                "cp deploy/bundled/.env.example deploy/bundled/.env (BUNDLED_SETUP §5)"
-            )
-    for key in facts.get("missing_keys", []):
-        blockers.append(f"deploy/bundled/.env: обязательный ключ {key} пуст")
-    if not resume:
-        for port in facts.get("busy_ports", []):
-            blockers.append(
-                f"порт {port} уже занят на хосте — освободите его или смените "
-                f"BUNDLE_*-порт в deploy/bundled/.env (BUNDLED_SETUP §2)"
-            )
-    ram = facts.get("ram_gb")
-    if ram is not None and ram < MIN_RAM_GB:
-        blockers.append(
-            f"RAM {ram:.1f} GB < минимума {MIN_RAM_GB} GB (Plane ≈ 14 контейнеров, "
-            f"BUNDLED_SETUP §2)"
-        )
-    disk = facts.get("disk_gb")
-    if disk is not None and disk < MIN_DISK_GB:
-        blockers.append(f"свободный диск {disk:.0f} GB < минимума {MIN_DISK_GB} GB")
-    cpus = facts.get("cpus")
-    if cpus is not None and cpus < MIN_CPUS:
-        warnings.append(f"CPU {cpus} < рекомендуемых {MIN_CPUS} vCPU — стек будет медленным")
-    if not facts.get("python3", True):
-        blockers.append("python3/venv недоступны — нужны для onboard-кирпича (TR-9)")
-    if not facts.get("claude_cli"):
-        warnings.append(
-            "Claude CLI/креды не найдены на хосте — стек поднимется, но конвейер "
-            "без LLM не поедет (BUNDLED_SETUP §8)"
-        )
-    return blockers, warnings, resume
-
-
-def build_plan() -> list:
-    """Нормативный план apply (нумерация — TRZ FR-2; механика — ADR-001 D5)."""
-    return [
-        ("preflight", "fail-fast проверки хоста ДО любых мутаций (BR-7)"),
-        ("secrets", "новые секреты инсталляции: gen_secrets.py + bundle-креды (FR-3)"),
-        ("up", "подъём bundle-compose + ожидание готовности (миграции Plane/Gitea)"),
-        ("init-gitea", "админ-бот + API-токен через `gitea admin ...` (полностью автоматом)"),
-        ("init-plane", "instance-setup/workspace/API-токен — manual-step с верификацией"),
-        ("plane-webhook", "workspace-webhook Plane → орк (ensure либо manual-step + проверка)"),
-        ("onboard", "sandbox-проект строго через onboard_project.py apply+verify (BR-6)"),
-        ("agent-git", "git-доступ агентов: клон sandbox-репо token-remote в /repos (D8)"),
-        ("orch-env", "сборка корневых .env/.env.watchdog + пересоздание орка/watchdog"),
-        ("health", "GET /health, /queue, /metrics + итоговая сводка PASS/FAIL"),
-    ]
-
-
-def build_arg_parser() -> argparse.ArgumentParser:
-    """CLI: режимы plan (дефолт) / apply / verify + параметры sandbox."""
-    parser = argparse.ArgumentParser(
-        description="Bootstrap Bundled-инсталляции (ORCH-103). Канон — "
-                    f"{DOC}."
-    )
-    parser.add_argument(
-        "mode", nargs="?", default="plan", choices=("plan", "apply", "verify"),
-        help="plan — дефолт, ноль мутаций; apply — прогон; verify — пост-проверка",
-    )
-    parser.add_argument(
-        "--force-secrets", action="store_true",
-        help="регенерировать СУЩЕСТВУЮЩИЕ bundle-креды (только ДО первого up!)",
-    )
-    parser.add_argument("--sandbox-name", default=SANDBOX_DEFAULTS["name"])
-    parser.add_argument("--sandbox-repo", default=SANDBOX_DEFAULTS["repo"])
-    parser.add_argument("--sandbox-prefix", default=SANDBOX_DEFAULTS["prefix"])
-    parser.add_argument("--sandbox-stack", default=SANDBOX_DEFAULTS["stack"])
-    parser.add_argument("--sandbox-test-cmd", default=SANDBOX_DEFAULTS["test_cmd"])
-    parser.add_argument("--sandbox-prod-port", default=SANDBOX_DEFAULTS["prod_port"])
-    parser.add_argument("--sandbox-staging-port", default=SANDBOX_DEFAULTS["staging_port"])
-    return parser
-
-
-# --------------------------------------------------------------------------- #
-# Тонкие обёртки subprocess/HTTP (единственные точки side-effects)
-# --------------------------------------------------------------------------- #
-
-def _run(cmd: list, input_text: str | None = None, env: dict | None = None,
-         timeout: int = 600) -> subprocess.CompletedProcess:
-    """subprocess.run c capture; команды логируются БЕЗ секретов вызывающим."""
-    return subprocess.run(
-        cmd, input=input_text, env=env, capture_output=True, text=True,
-        timeout=timeout, check=False,
-    )
-
-
-def _compose(*args: str, input_text: str | None = None,
-             timeout: int = 600) -> subprocess.CompletedProcess:
-    return _run(["docker", "compose", "-f", BUNDLE_COMPOSE, *args],
-                input_text=input_text, timeout=timeout)
-
-
-def _http(url: str, headers: dict | None = None, timeout: int = 10) -> tuple:
-    """GET url → (status|None, body). Никогда не бросает (poll-friendly)."""
-    req = urllib.request.Request(url, headers=headers or {})
-    try:
-        with urllib.request.urlopen(req, timeout=timeout) as resp:  # noqa: S310
-            return resp.status, resp.read().decode("utf-8", "replace")
-    except urllib.error.HTTPError as e:
-        return e.code, ""
-    except (urllib.error.URLError, OSError, ValueError):
-        return None, ""
-
-
-def _port_busy(port: int) -> bool:
-    with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
-        s.settimeout(0.5)
-        return s.connect_ex(("127.0.0.1", port)) == 0
-
-
-def _write_private(path: str, content: str) -> None:
-    """Запись live-конфига: права 600, без печати содержимого (NFR-3)."""
-    with open(path, "w", encoding="utf-8") as f:
-        f.write(content)
-    os.chmod(path, 0o600)
-    log(f"  записан {os.path.relpath(path, REPO_ROOT)} (права 600)")
-
-
-def update_env_file(path: str, example_path: str, overrides: dict) -> None:
-    """Идемпотентный ensure env-файла: существующий — обновить ключи overrides,
-    отсутствующий — отрендерить от канона-example. Никаких удалений."""
-    if os.path.isfile(path):
-        base = open(path, encoding="utf-8").read()
-    else:
-        base = open(example_path, encoding="utf-8").read()
-    _write_private(path, render_env(base, overrides))
-
-
-# --------------------------------------------------------------------------- #
-# Сбор фактов хоста (read-only; используется plan/apply/verify)
-# --------------------------------------------------------------------------- #
-
-def bundle_ports(bundle_env: dict) -> list:
-    out = []
-    for key, default in (("BUNDLE_ORCH_PORT", 8500), ("BUNDLE_PLANE_PORT", 8080),
-                         ("BUNDLE_GITEA_HTTP_PORT", 3000)):
-        try:
-            out.append(int(bundle_env.get(key) or default))
-        except ValueError:
-            out.append(default)
-    return out
-
-
-def collect_facts(bundle_env: dict) -> dict:
-    """Read-only снимок хоста для preflight_verdict (ни одной мутации)."""
-    docker = shutil.which("docker") is not None
-    compose = docker and _compose("version", timeout=30).returncode == 0
-    leftovers: list = []
-    if docker:
-        vols = _run(["docker", "volume", "ls", "--format", "{{.Name}}"], timeout=30)
-        names = _run(["docker", "ps", "-a", "--format", "{{.Names}}"], timeout=30)
-        for line in (vols.stdout + "\n" + names.stdout).splitlines():
-            if line.strip().startswith(PROJECT):
-                leftovers.append(line.strip())
-    ram_gb = None
-    try:
-        with open("/proc/meminfo", encoding="utf-8") as f:
-            for line in f:
-                if line.startswith("MemTotal:"):
-                    ram_gb = int(line.split()[1]) / 1024 / 1024
-                    break
-    except OSError:
-        pass
-    try:
-        disk_gb = shutil.disk_usage(REPO_ROOT).free / 2**30
-    except OSError:
-        disk_gb = None
-    env_exists = os.path.isfile(BUNDLE_ENV)
-    missing = [k for k in REQUIRED_BUNDLE_KEYS if not bundle_env.get(k, "")]
-    claude_ok = (
-        shutil.which("claude") is not None
-        or os.path.isdir(os.path.expanduser(
-            bundle_env.get("ORCH_HOST_CLAUDE_DIR", "") or "~/.claude"))
-    )
-    return {
-        "docker": docker,
-        "compose": compose,
-        "env_exists": env_exists,
-        "missing_keys": missing if env_exists else [],
-        "busy_ports": [p for p in bundle_ports(bundle_env) if _port_busy(p)],
-        "leftovers": leftovers,
-        "ram_gb": ram_gb,
-        "disk_gb": disk_gb,
-        "cpus": os.cpu_count(),
-        "python3": True,  # мы уже исполняемся под python3
-        "claude_cli": claude_ok,
-    }
-
-
-# --------------------------------------------------------------------------- #
-# Manual-step контракт (D5/D7): инструкция → подтверждение → верификация
-# --------------------------------------------------------------------------- #
-
-def manual_checkpoint(title: str, instructions: list, verify, max_tries: int = 3):
-    """Честный чекпоинт: печать точной инструкции; без TTY — немедленный exit 2
-    с той же инструкцией; с TTY — ожидание подтверждения и ВЕРИФИКАЦИЯ результата
-    (молчаливый пропуск запрещён). verify() → (ok, hint)."""
-    log(f"\n🖐 MANUAL-STEP: {title}")
-    for line in instructions:
-        log(f"   {line}")
-    if not sys.stdin.isatty():
-        log("   Нет TTY: выполните шаги и перезапустите `apply` (resume = повторный запуск).")
-        raise ManualStop(title)
-    for _ in range(max_tries):
-        input("   Когда выполнено — нажмите Enter: ")
-        ok, hint = verify()
-        if ok:
-            log("   ✓ верификация пройдена")
-            return
-        log(f"   ✗ верификация не прошла: {hint}")
-    raise ManualStop(f"{title}: верификация не прошла после {max_tries} попыток")
-
-
-# --------------------------------------------------------------------------- #
-# Шаги apply (step-движок check→ensure; каждый идемпотентен)
-# --------------------------------------------------------------------------- #
-
-def step_preflight(ctx: dict) -> str:
-    facts = collect_facts(ctx["bundle_env"])
-    blockers, warnings, resume = preflight_verdict(facts)
-    for w in warnings:
-        log(f"  ⚠ {w}")
-    if blockers:
-        for b in blockers:
-            log(f"  ✗ {b}")
-        raise ManualStop("preflight: незавершённые предусловия хоста")
-    ctx["resume"] = resume
-    if resume:
-        log("  инсталляция уже существует — продолжаю в ensure-режиме (AC-8)")
-    return "ok"
-
-
-def step_secrets(ctx: dict) -> str:
-    """FR-3: bundle-креды (stdlib secrets) + webhook-секреты (gen_secrets.py)."""
-    force = ctx["args"].force_secrets
-    bundle_env = ctx["bundle_env"]
-    fresh = merge_missing_secrets(bundle_env, force=force)
-    # uid/gid/docker-gid хоста — дозаполняются фактическими значениями оператора
-    infra: dict = {}
-    if not bundle_env.get("ORCH_RUN_UID"):
-        infra["ORCH_RUN_UID"] = str(os.getuid())
-    if not bundle_env.get("ORCH_RUN_GID"):
-        infra["ORCH_RUN_GID"] = str(os.getgid())
-    if fresh or infra:
-        update_env_file(BUNDLE_ENV, BUNDLE_ENV_EXAMPLE, {**infra, **fresh})
-        ctx["bundle_env"] = parse_env(open(BUNDLE_ENV, encoding="utf-8").read())
-        log(f"  bundle-креды выпущены: {', '.join(sorted(fresh)) or '—'}")
-    else:
-        log("  bundle-креды уже на месте (не перетираю без --force-secrets)")
-    # webhook-секреты орка — СТРОГО кирпичом gen_secrets.py (AC-7)
-    root_env = ctx["root_env"]
-    if all(root_env.get(k) for k in WEBHOOK_SECRET_KEYS) and not force:
-        log("  webhook-секреты уже в .env — skip")
-        return "skipped"
-    with tempfile.TemporaryDirectory() as tmp:
-        frag_path = os.path.join(tmp, "fragment.env")
-        proc = _run([sys.executable, GEN_SECRETS, "--write", frag_path], timeout=60)
-        if proc.returncode != 0:
-            raise BootstrapError(f"gen_secrets.py отказал (rc={proc.returncode})")
-        fragment = parse_env(open(frag_path, encoding="utf-8").read())
-    overrides = {k: fragment[k] for k in WEBHOOK_SECRET_KEYS
-                 if fragment.get(k) and (force or not root_env.get(k))}
-    update_env_file(ROOT_ENV, ROOT_ENV_EXAMPLE, overrides)
-    ctx["root_env"] = parse_env(open(ROOT_ENV, encoding="utf-8").read())
-    log(f"  webhook-секреты выпущены: {', '.join(sorted(overrides)) or '—'}")
-    return "ok"
-
-
-def _wait_http(url: str, timeout_s: int, label: str, ok_statuses=(200,)) -> None:
-    deadline = time.monotonic() + timeout_s
-    while time.monotonic() < deadline:
-        status, _ = _http(url, timeout=5)
-        if status in ok_statuses:
-            log(f"  ✓ {label} готов ({url})")
-            return
-        time.sleep(5)
-    tail = _compose("logs", "--tail", "30", label, timeout=60).stdout[-2000:]
-    raise BootstrapError(f"{label} не дождались за {timeout_s}с ({url}); хвост логов:\n{tail}")
-
-
-def _wait_migrator(timeout_s: int) -> None:
-    deadline = time.monotonic() + timeout_s
-    name = f"{PROJECT}-migrator-1"
-    while time.monotonic() < deadline:
-        proc = _run(["docker", "inspect", "-f",
-                     "{{.State.Status}} {{.State.ExitCode}}", name], timeout=30)
-        state = proc.stdout.strip()
-        if proc.returncode == 0 and state.startswith("exited"):
-            if state.endswith(" 0"):
-                log("  ✓ миграции Plane завершились (migrator exit 0)")
-                return
-            tail = _compose("logs", "--tail", "30", "migrator", timeout=60).stdout[-2000:]
-            raise BootstrapError(f"миграции Plane упали ({state}); хвост логов:\n{tail}")
-        time.sleep(5)
-    raise BootstrapError(f"миграции Plane не завершились за {timeout_s}с (TR-1: проверьте RAM/диск)")
-
-
-def step_up(ctx: dict) -> str:
-    """Подъём стека + ожидание готовности каждого слоя (D5 шаг 3)."""
-    for sub in ("data", "repos"):
-        os.makedirs(os.path.join(BUNDLE_DIR, sub), exist_ok=True)
-    proc = _compose("up", "-d", timeout=1800)
-    if proc.returncode != 0:
-        raise BootstrapError(f"docker compose up отказал:\n{proc.stderr[-2000:]}")
-    ports = dict(zip(("orch", "plane", "gitea"), bundle_ports(ctx["bundle_env"])))
-    _wait_http(f"http://127.0.0.1:{ports['gitea']}/api/healthz", READY_TIMEOUT_S, "gitea")
-    _wait_migrator(PLANE_READY_TIMEOUT_S)
-    _wait_http(f"http://127.0.0.1:{ports['plane']}/", PLANE_READY_TIMEOUT_S,
-               "proxy", ok_statuses=(200, 301, 302))
-    _wait_http(f"http://127.0.0.1:{ports['orch']}/health", READY_TIMEOUT_S, "orchestrator")
-    return "ok"
-
-
-def step_init_gitea(ctx: dict) -> str:
-    """D6: админ-бот + API-токен официальным CLI в контейнере; идемпотентно.
-    Branch protection НЕ настраивается (норматив D10 ORCH-009 / INV-4)."""
-    bundle_env, root_env = ctx["bundle_env"], ctx["root_env"]
-    user = bundle_env.get("GITEA_ADMIN_USERNAME", "orchestrator-bot")
-    gitea_port = bundle_ports(bundle_env)[2]
-    ctx["gitea_owner"] = user
-    proc = _compose(
-        "exec", "-T", "-u", "git", "gitea",
-        "gitea", "admin", "user", "create", "--admin",
-        "--username", user, "--password", bundle_env.get("GITEA_ADMIN_PASSWORD", ""),
-        "--email", f"{user}@{PROJECT}.local", "--must-change-password=false",
-        timeout=120,
-    )
-    blob = proc.stdout + proc.stderr
-    if proc.returncode == 0:
-        log(f"  создан админ-бот Gitea: {user}")
-    elif "already exists" in blob:
-        log(f"  админ-бот {user} уже существует — skip")
-    else:
-        raise BootstrapError(f"gitea admin user create отказал: {blob[-500:]}")
-    # API-токен (носитель — root .env, ORCH_GITEA_TOKEN)
-    token = root_env.get("ORCH_GITEA_TOKEN", "")
-    if token:
-        status, _ = _http(f"http://127.0.0.1:{gitea_port}/api/v1/user",
-                          headers={"Authorization": f"token {token}"})
-        if status == 200:
-            log("  ORCH_GITEA_TOKEN валиден — skip")
-            return "skipped"
-    proc = _compose(
-        "exec", "-T", "-u", "git", "gitea",
-        "gitea", "admin", "user", "generate-access-token",
-        "--username", user, "--token-name", f"orchestrator-{int(time.time())}",
-        "--scopes", "all", "--raw",
-        timeout=120,
-    )
-    if proc.returncode != 0:
-        raise BootstrapError(f"generate-access-token отказал: {proc.stderr[-500:]}")
-    token = proc.stdout.strip().splitlines()[-1].strip()
-    status, _ = _http(f"http://127.0.0.1:{gitea_port}/api/v1/user",
-                      headers={"Authorization": f"token {token}"})
-    if status != 200:
-        raise BootstrapError(f"свежий токен Gitea не прошёл верификацию (HTTP {status})")
-    update_env_file(ROOT_ENV, ROOT_ENV_EXAMPLE,
-                    {"ORCH_GITEA_TOKEN": token, "ORCH_GITEA_OWNER": user})
-    ctx["root_env"] = parse_env(open(ROOT_ENV, encoding="utf-8").read())
-    log("  выпущен ORCH_GITEA_TOKEN (значение в .env, не печатается)")
-    return "ok"
-
-
-def _verify_plane_token(plane_port: int, slug: str, token: str) -> tuple:
-    status, _ = _http(
-        f"http://127.0.0.1:{plane_port}/api/v1/workspaces/{slug}/projects/",
-        headers={"X-API-Key": token}, timeout=15,
-    )
-    if status == 200:
-        return True, ""
-    return False, f"GET /api/v1/workspaces/{slug}/projects/ → HTTP {status}"
-
-
-def step_init_plane(ctx: dict) -> str:
-    """D7: instance-setup / workspace / API-токен — честные manual-step
-    чекпоинты (Plane CE не даёт API первичной инициализации)."""
-    bundle_env, root_env = ctx["bundle_env"], ctx["root_env"]
-    host = bundle_env.get("BUNDLE_PUBLIC_HOST", "localhost")
-    plane_port = bundle_ports(bundle_env)[1]
-    slug = root_env.get("ORCH_PLANE_WORKSPACE_SLUG", "")
-    token = root_env.get("ORCH_PLANE_API_TOKEN", "")
-    if slug and token and _verify_plane_token(plane_port, slug, token)[0]:
-        log("  workspace и ORCH_PLANE_API_TOKEN валидны — skip")
-        return "skipped"
-
-    def _instance_done():
-        status, body = _http(f"http://127.0.0.1:{plane_port}/api/instances/", timeout=10)
-        if status == 200 and '"is_setup_done":true' in body.replace(" ", ""):
-            return True, ""
-        if status == 200:
-            return False, "instance setup ещё не завершён (is_setup_done != true)"
-        # эндпоинт недоступен в этой сборке CE → деградация: живость UI
-        ui, _ = _http(f"http://127.0.0.1:{plane_port}/", timeout=10)
-        return (ui in (200, 301, 302)), f"Plane UI отвечает HTTP {ui}"
-
-    manual_checkpoint(
-        "Plane: instance setup (первый администратор)",
-        [f"Откройте http://{host}:{plane_port}/ и зарегистрируйте первого",
-         "пользователя — он станет администратором инстанса (Plane CE)."],
-        _instance_done,
-    )
-    if not sys.stdin.isatty():
-        raise ManualStop("Plane: workspace/API-токен требуют интерактивного ввода")
-    slug = input("   Введите slug созданного workspace: ").strip()
-    log("   Plane UI → Workspace Settings → API tokens → выпустите токен.")
-    token = getpass.getpass("   Вставьте ORCH_PLANE_API_TOKEN (ввод скрыт): ").strip()
-    ok, hint = _verify_plane_token(plane_port, slug, token)
-    if not ok:
-        raise ManualStop(f"Plane: токен/slug не прошли верификацию ({hint})")
-    update_env_file(ROOT_ENV, ROOT_ENV_EXAMPLE,
-                    {"ORCH_PLANE_WORKSPACE_SLUG": slug, "ORCH_PLANE_API_TOKEN": token})
-    ctx["root_env"] = parse_env(open(ROOT_ENV, encoding="utf-8").read())
-    log("  ✓ workspace и ORCH_PLANE_API_TOKEN верифицированы (значения в .env)")
-    return "ok"
-
-
-def _psql(sql: str, bundle_env: dict) -> subprocess.CompletedProcess:
-    """SQL в plane-db через stdin (секреты не попадают в argv, NFR-3)."""
-    return _compose(
-        "exec", "-T", "plane-db", "psql",
-        "-U", bundle_env.get("POSTGRES_USER", "plane"),
-        "-d", bundle_env.get("POSTGRES_DB", "plane"),
-        "-t", "-A", "-v", "ON_ERROR_STOP=1",
-        input_text=sql, timeout=60,
-    )
-
-
-def step_plane_webhook(ctx: dict) -> str:
-    """Workspace-webhook Plane→орк. CE не даёт API → ensure прямой записью в
-    Postgres инсталляции (прогрессивная автоматизация D7: контракт чекпоинта —
-    та же верификация SELECT'ом); схема — канон LITE_SETUP §5.4 (путь Б)."""
-    bundle_env, root_env = ctx["bundle_env"], ctx["root_env"]
-    secret = root_env.get("ORCH_PLANE_WEBHOOK_SECRET", "")
-    slug = root_env.get("ORCH_PLANE_WORKSPACE_SLUG", "")
-    if not (secret and slug):
-        raise BootstrapError("нет ORCH_PLANE_WEBHOOK_SECRET/ORCH_PLANE_WORKSPACE_SLUG в .env")
-
-    def _exists() -> tuple:
-        probe = _psql(
-            f"SELECT count(*) FROM webhooks WHERE url='{WEBHOOK_PLANE_URL}' "
-            f"AND deleted_at IS NULL;", bundle_env)
-        ok = probe.returncode == 0 and probe.stdout.strip().isdigit() \
-            and int(probe.stdout.strip()) > 0
-        return ok, f"SELECT по webhooks: rc={probe.returncode}"
-
-    if _exists()[0]:
-        log("  workspace-webhook уже зарегистрирован — skip")
-        return "skipped"
-    wid = _psql(f"SELECT id FROM workspaces WHERE slug='{slug}';", bundle_env)
-    workspace_id = wid.stdout.strip().splitlines()[0].strip() if wid.stdout.strip() else ""
-    if wid.returncode == 0 and workspace_id:
-        ins = _psql(
-            "INSERT INTO webhooks (id, created_at, updated_at, deleted_at, "
-            "workspace_id, url, is_active, secret_key, project, issue, module, "
-            "cycle, issue_comment, is_internal, version) VALUES "
-            f"('{uuid.uuid4()}', NOW(), NOW(), NULL, '{workspace_id}', "
-            f"'{WEBHOOK_PLANE_URL}', true, '{secret}', true, true, false, false, "
-            "true, false, 'v1');", bundle_env)
-        if ins.returncode == 0 and _exists()[0]:
-            log(f"  ✓ workspace-webhook зарегистрирован: {WEBHOOK_PLANE_URL}")
-            return "ok"
-        log("  прямая регистрация не удалась — честный manual-step (fail-safe)")
-    manual_checkpoint(
-        "Plane: workspace-webhook (CE без API)",
-        [f"Workspace Settings → Webhooks → Add Webhook: URL {WEBHOOK_PLANE_URL},",
-         "секрет — значение ORCH_PLANE_WEBHOOK_SECRET из корневого .env,",
-         "события Issue + Issue Comment (канон — LITE_SETUP §5.4)."],
-        _exists,
-    )
-    return "ok"
-
-
-def _ensure_venv() -> str:
-    """Host-venv для onboard-кирпича (канон ONBOARDING; ensure, TR-9)."""
-    if not os.path.exists(VENV_PY):
-        proc = _run([sys.executable, "-m", "venv", VENV_DIR], timeout=300)
-        if proc.returncode != 0:
-            raise BootstrapError(f"python3 -m venv отказал: {proc.stderr[-500:]}")
-    probe = _run([VENV_PY, "-c", "import httpx, pydantic"], timeout=60)
-    if probe.returncode != 0:
-        log("  ставлю зависимости onboard-кирпича в .venv (requirements.txt)…")
-        proc = _run([VENV_PY, "-m", "pip", "install", "-q", "-r", REQUIREMENTS],
-                    timeout=1200)
-        if proc.returncode != 0:
-            raise BootstrapError(f"pip install отказал: {proc.stderr[-500:]}")
-    return VENV_PY
-
-
-def _onboard_env(ctx: dict) -> dict:
-    """Окружение onboard-субпроцесса: host-видимые URL bundle-инсталляции
-    (pydantic env-переменные перекрывают env_file, D7)."""
-    bundle_env, root_env = ctx["bundle_env"], ctx["root_env"]
-    host = bundle_env.get("BUNDLE_PUBLIC_HOST", "localhost")
-    plane_p, gitea_p = bundle_ports(bundle_env)[1:]
-    return {
-        **os.environ,
-        "ORCH_PLANE_API_URL": f"http://127.0.0.1:{plane_p}",
-        "ORCH_PLANE_WEB_URL": f"http://{host}:{plane_p}",
-        "ORCH_PLANE_WORKSPACE_SLUG": root_env.get("ORCH_PLANE_WORKSPACE_SLUG", ""),
-        "ORCH_PLANE_API_TOKEN": root_env.get("ORCH_PLANE_API_TOKEN", ""),
-        "ORCH_GITEA_URL": f"http://127.0.0.1:{gitea_p}",
-        "ORCH_GITEA_PUBLIC_URL": f"http://{host}:{gitea_p}",
-        "ORCH_GITEA_OWNER": root_env.get("ORCH_GITEA_OWNER", ""),
-        "ORCH_GITEA_TOKEN": root_env.get("ORCH_GITEA_TOKEN", ""),
-        "ORCH_GITEA_WEBHOOK_SECRET": root_env.get("ORCH_GITEA_WEBHOOK_SECRET", ""),
-    }
-
-
-def _onboard_args(ctx: dict, mode: str) -> list:
-    a = ctx["args"]
-    return [
-        ONBOARD, mode,
-        "--name", a.sandbox_name, "--repo", a.sandbox_repo,
-        "--gitea-owner", ctx["root_env"].get("ORCH_GITEA_OWNER", ""),
-        "--prefix", a.sandbox_prefix, "--stack", a.sandbox_stack,
-        "--test-cmd", a.sandbox_test_cmd,
-        "--prod-port", a.sandbox_prod_port, "--staging-port", a.sandbox_staging_port,
-        "--webhook-url", WEBHOOK_GITEA_URL,
-        "--env-file", ROOT_ENV, "--json",
-    ]
-
-
-def step_onboard(ctx: dict) -> str:
-    """BR-6/AC-7: статусы/лейблы/репо/вебхуки — СТРОГО onboard_project.py."""
-    venv_py = _ensure_venv()
-    env = _onboard_env(ctx)
-    proc = _run([venv_py, *_onboard_args(ctx, "apply")], env=env, timeout=900)
-    if proc.returncode not in (0, 2):
-        raise BootstrapError(f"onboard apply отказал (rc={proc.returncode}): "
-                             f"{proc.stderr[-800:]}")
-    try:
-        report = json.loads(proc.stdout)
-    except ValueError:
-        raise BootstrapError("onboard apply вернул непарсимый отчёт")
-    merged = ""
-    for instr in report.get("instructions", []):
-        if isinstance(instr, str) and instr.startswith("ORCH_PROJECTS_JSON="):
-            merged = instr.split("=", 1)[1]
-    if merged:
-        update_env_file(ROOT_ENV, ROOT_ENV_EXAMPLE, {"ORCH_PROJECTS_JSON": merged})
-        ctx["root_env"] = parse_env(open(ROOT_ENV, encoding="utf-8").read())
-        log("  реестр ORCH_PROJECTS_JSON записан в .env (merged-вывод onboard)")
-    manual = [s for s in report.get("steps", [])
-              if s.get("status") == "manual-step"
-              and s.get("id") not in ("plane.workspace-webhook",)]
-    if manual:
-        log("  onboard оставил ручные шаги (см. отчёт): "
-            + ", ".join(s.get("id", "?") for s in manual))
-    verify = _run([venv_py, *_onboard_args(ctx, "verify")], env=env, timeout=300)
-    if verify.returncode == 1:
-        raise BootstrapError(f"onboard verify отказал: {verify.stderr[-800:]}")
-    log(f"  onboard verify: exit {verify.returncode} "
-        f"(0 — чисто; 2 — остались ручные пункты отчёта)")
-    ctx["onboard_manual"] = bool(manual) or verify.returncode == 2
-    return "ok"
-
-
-def step_agent_git(ctx: dict) -> str:
-    """D8: клон sandbox-репо token-remote ВНУТРИ контейнера орка (origin —
-    in-network gitea:3000, агенты наследуют его для push/fetch)."""
-    repo = ctx["args"].sandbox_repo
-    owner = ctx["root_env"].get("ORCH_GITEA_OWNER", "")
-    token = ctx["root_env"].get("ORCH_GITEA_TOKEN", "")
-    probe = _compose("exec", "-T", "orchestrator", "test", "-d",
-                     f"/repos/{repo}/.git", timeout=30)
-    if probe.returncode == 0:
-        log(f"  /repos/{repo} уже клонирован — skip")
-        return "skipped"
-    url = f"{GITEA_INTERNAL_URL.split('://')[0]}://oauth2:{token}@" \
-          f"{GITEA_INTERNAL_URL.split('://')[1]}/{owner}/{repo}.git"
-    proc = _compose("exec", "-T", "orchestrator",
-                    "git", "clone", url, f"/repos/{repo}", timeout=300)
-    if proc.returncode != 0:
-        raise BootstrapError(
-            f"клон {repo} в /repos не удался (лог замаскирован): rc={proc.returncode}")
-    log(f"  ✓ /repos/{repo} клонирован (token-remote, TR-7: права локального каталога)")
-    return "ok"
-
-
-def step_orch_env(ctx: dict) -> str:
-    """D5 шаг 8: корневой .env (канон Lite 1:1) + .env.watchdog; пересоздание
-    орка/watchdog для подхвата конфига."""
-    bundle_env = ctx["bundle_env"]
-    host = bundle_env.get("BUNDLE_PUBLIC_HOST", "localhost")
-    plane_p, gitea_p = bundle_ports(bundle_env)[1:]
-    overrides = {
-        # in-network машинные URL (D4) + публичные от BUNDLE_PUBLIC_HOST
-        "ORCH_PLANE_API_URL": PLANE_INTERNAL_URL,
-        "ORCH_PLANE_WEB_URL": f"http://{host}:{plane_p}",
-        "ORCH_GITEA_URL": GITEA_INTERNAL_URL,
-        "ORCH_GITEA_PUBLIC_URL": f"http://{host}:{gitea_p}",
-        # когерентность дублируемых ключей — механически (TR-8)
-        "ORCH_AGENT_HOME_DIR": bundle_env.get("ORCH_AGENT_HOME_DIR", "/home/orchestrator"),
-        "ORCH_RUN_UID": bundle_env.get("ORCH_RUN_UID", "1000"),
-        "ORCH_RUN_GID": bundle_env.get("ORCH_RUN_GID", "1000"),
-        "ORCH_DOCKER_GID": bundle_env.get("ORCH_DOCKER_GID", "999"),
-        "ORCH_HOST_REPOS_DIR": os.path.join(BUNDLE_DIR, "repos"),
-        "ORCH_HOST_CLAUDE_CODE_DIR": bundle_env.get("ORCH_HOST_CLAUDE_CODE_DIR", ""),
-        "ORCH_HOST_NODE_BIN": bundle_env.get("ORCH_HOST_NODE_BIN", ""),
-        "ORCH_HOST_CLAUDE_DIR": bundle_env.get("ORCH_HOST_CLAUDE_DIR", ""),
-        "ORCH_HOST_CLAUDE_JSON": bundle_env.get("ORCH_HOST_CLAUDE_JSON", ""),
-        # деплой-машинерия нашего хоста в bundle структурно спит (D4)
-        "ORCH_DEPLOY_SSH_HOST": "",
-    }
-    update_env_file(ROOT_ENV, ROOT_ENV_EXAMPLE, overrides)
-    ctx["root_env"] = parse_env(open(ROOT_ENV, encoding="utf-8").read())
-    if not os.path.isfile(WATCHDOG_ENV):
-        # Telegram-ключи опциональны: пусто = деградация только нотификаций
-        update_env_file(WATCHDOG_ENV, WATCHDOG_ENV_EXAMPLE, {})
-    proc = _compose("up", "-d", "--force-recreate",
-                    "orchestrator", "orchestrator-watchdog", timeout=600)
-    if proc.returncode != 0:
-        raise BootstrapError(f"пересоздание орка/watchdog отказало:\n{proc.stderr[-1000:]}")
-    log("  ✓ орк и watchdog пересозданы с собранным конфигом")
-    return "ok"
-
-
-def step_health(ctx: dict) -> str:
-    orch_p = bundle_ports(ctx["bundle_env"])[0]
-    failures = []
-    for path in ("/health", "/queue", "/metrics"):
-        url = f"http://127.0.0.1:{orch_p}{path}"
-        status, body = None, ""
-        deadline = time.monotonic() + 60
-        while time.monotonic() < deadline:
-            status, body = _http(url, timeout=5)
-            if status == 200:
-                break
-            time.sleep(3)
-        ok = status == 200
-        if path != "/health" and ok:
-            try:
-                json.loads(body)
-            except ValueError:
-                ok = False
-        log(f"  GET {path} → {'PASS' if ok else f'FAIL (HTTP {status})'}")
-        if not ok:
-            failures.append(path)
-    if failures:
-        raise BootstrapError(f"health-контракты не зелёные: {', '.join(failures)}")
-    return "ok"
-
-
-APPLY_STEPS = (
-    ("preflight", step_preflight),
-    ("secrets", step_secrets),
-    ("up", step_up),
-    ("init-gitea", step_init_gitea),
-    ("init-plane", step_init_plane),
-    ("plane-webhook", step_plane_webhook),
-    ("onboard", step_onboard),
-    ("agent-git", step_agent_git),
-    ("orch-env", step_orch_env),
-    ("health", step_health),
-)
-
-
-# --------------------------------------------------------------------------- #
-# Режимы
-# --------------------------------------------------------------------------- #
-
-def _load_ctx(args: argparse.Namespace) -> dict:
-    bundle_env = parse_env(open(BUNDLE_ENV, encoding="utf-8").read()) \
-        if os.path.isfile(BUNDLE_ENV) else {}
-    root_env = parse_env(open(ROOT_ENV, encoding="utf-8").read()) \
-        if os.path.isfile(ROOT_ENV) else {}
-    return {"args": args, "bundle_env": bundle_env, "root_env": root_env,
-            "results": {}}
-
-
-def run_plan(ctx: dict) -> int:
-    log("== bootstrap_bundle: план apply (ноль мутаций) ==")
-    for i, (name, summary) in enumerate(build_plan(), 1):
-        log(f"  {i}. {name:<14} {summary}")
-    facts = collect_facts(ctx["bundle_env"])
-    blockers, warnings, resume = preflight_verdict(facts)
-    log("\n-- preflight-диагностика (read-only):")
-    for w in warnings:
-        log(f"  ⚠ {w}")
-    for b in blockers:
-        log(f"  ✗ {b}")
-    if resume:
-        log("  ℹ найдены тома/контейнеры orchestrator-bundle: apply пойдёт в ensure-режиме")
-    if not blockers:
-        log("  ✓ предусловия хоста выполнены — запускайте: "
-            "python3 scripts/bootstrap_bundle.py apply")
-        return EXIT_OK
-    log(f"  итог: {len(blockers)} блокеров — устраните и повторите (канон — {DOC})")
-    return EXIT_MANUAL
-
-
-def run_apply(ctx: dict) -> int:
-    log("== bootstrap_bundle: apply ==")
-    for name, fn in APPLY_STEPS:
-        log(f"\n→ шаг {name}")
-        status = fn(ctx)
-        ctx["results"][name] = status
-    log("\n== итоговая сводка ==")
-    for name, _ in APPLY_STEPS:
-        log(f"  [{ctx['results'].get(name, '—'):>8}] {name}")
-    if ctx.get("onboard_manual"):
-        log("\n🖐 Остались ручные пункты onboard-отчёта (порядок статусов на доске и т.п.)")
-        log("   Выполните их и перезапустите verify. Exit 2 (незавершённые шаги).")
-        return EXIT_MANUAL
-    log(f"\n✓ Bundled-инсталляция готова. Следующий шаг — smoke: {DOC} §11 "
-        "(чек-лист REPLICATION.md §4).")
-    return EXIT_OK
-
-
-def run_verify(ctx: dict) -> int:
-    """Read-only пост-проверка: health-контракты + onboard verify."""
-    log("== bootstrap_bundle: verify (read-only) ==")
-    orch_p = bundle_ports(ctx["bundle_env"])[0]
-    failed = False
-    for path in ("/health", "/queue", "/metrics"):
-        status, _ = _http(f"http://127.0.0.1:{orch_p}{path}", timeout=10)
-        ok = status == 200
-        failed = failed or not ok
-        log(f"  GET {path} → {'PASS' if ok else f'FAIL (HTTP {status})'}")
-    if os.path.exists(VENV_PY) and ctx["root_env"].get("ORCH_PLANE_API_TOKEN"):
-        proc = _run([VENV_PY, *_onboard_args(ctx, "verify")],
-                    env=_onboard_env(ctx), timeout=300)
-        log(f"  onboard verify → exit {proc.returncode}")
-        failed = failed or proc.returncode == 1
-        if proc.returncode == 2:
-            return EXIT_MANUAL
-    else:
-        log("  onboard verify пропущен (нет .venv или ORCH_PLANE_API_TOKEN) → exit 2")
-        return EXIT_MANUAL
-    return EXIT_ERROR if failed else EXIT_OK
-
-
-def main(argv: list | None = None) -> int:
-    args = build_arg_parser().parse_args(argv)
-    ctx = _load_ctx(args)
-    try:
-        if args.mode == "plan":
-            return run_plan(ctx)
-        if args.mode == "verify":
-            return run_verify(ctx)
-        return run_apply(ctx)
-    except ManualStop as e:
-        log(f"\n🖐 ОСТАНОВКА (exit {EXIT_MANUAL}): {e}")
-        log("   Выполните шаг и перезапустите apply — завершённые шаги будут пропущены.")
-        return EXIT_MANUAL
-    except BootstrapError as e:
-        log(f"\n✗ ОШИБКА (exit {EXIT_ERROR}): {e}")
-        return EXIT_ERROR
-    except KeyboardInterrupt:
-        log(f"\n✗ прервано оператором (exit {EXIT_ERROR})")
-        return EXIT_ERROR
-
-
-if __name__ == "__main__":
-    sys.exit(main())

scripts/gen_secrets.py

@@ -1,147 +0,0 @@
-#!/usr/bin/env python3
-"""gen_secrets.py — выпуск НОВОГО комплекта секретов для нового хоста (ORCH-101).
-
-Provisioning-инструмент тиража (ADR-001 D8): генерирует криптослучайные
-webhook-секреты оркестратора и печатает .env-фрагмент с плейсхолдерами внешних
-токенов. Боевые секреты текущего хоста НЕ копируются ни на одном шаге — для
-нового хоста всегда выпускается новый комплект (AC-5).
-
-Состав (инвентаризация FR-4.1):
-  * генерируются локально (secrets.token_hex(32) — 32 байта энтропии, 64 hex):
-      ORCH_PLANE_WEBHOOK_SECRET, ORCH_GITEA_WEBHOOK_SECRET
-  * выпускаются внешними системами (только плейсхолдер + чек-лист в
-    docs/operations/REPLICATION.md: где выпустить -> куда вписать -> как
-    проверить): ORCH_PLANE_API_TOKEN, ORCH_PLANE_BOT_* (7, опциональны),
-    ORCH_GITEA_TOKEN, ORCH_TELEGRAM_BOT_TOKEN (+ несекретный
-    ORCH_TELEGRAM_CHAT_ID), sidecar WATCHDOG_TG_BOT_TOKEN / WATCHDOG_TG_CHAT_ID.
-
-Поведение (NFR-3): по умолчанию — ТОЛЬКО печать в stdout (файлы не трогаются).
-``--write [PATH]`` пишет фрагмент в файл (дефолт .env); СУЩЕСТВУЮЩИЙ файл ->
-отказ с exit-кодом 2 и внятным сообщением; перезапись — только явный
-``--force``. Повторный запуск всегда даёт другие значения секретов.
-
-stdlib-only (secrets, argparse) — никаких зависимостей платформы; скрипт
-работает на голом python3 целевого хоста до первого `docker compose up`.
-
-Запуск:
-    python3 scripts/gen_secrets.py                 # печать в stdout
-    python3 scripts/gen_secrets.py --write         # создать .env (если его нет)
-    python3 scripts/gen_secrets.py --write /tmp/e  # создать произвольный файл
-    python3 scripts/gen_secrets.py --write --force # перезаписать существующий
-"""
-
-import argparse
-import secrets
-import sys
-
-# Webhook-секреты, генерируемые локально на целевом хосте (FR-4.2).
-GENERATED_KEYS = (
-    "ORCH_PLANE_WEBHOOK_SECRET",
-    "ORCH_GITEA_WEBHOOK_SECRET",
-)
-
-# Секреты внешних систем: только плейсхолдеры (значения выпускает оператор —
-# чек-лист в docs/operations/REPLICATION.md). Имена согласованы с .env.example.
-EXTERNAL_KEYS = (
-    "ORCH_PLANE_API_TOKEN",
-    "ORCH_PLANE_BOT_ANALYST",
-    "ORCH_PLANE_BOT_ARCHITECT",
-    "ORCH_PLANE_BOT_DEVELOPER",
-    "ORCH_PLANE_BOT_REVIEWER",
-    "ORCH_PLANE_BOT_TESTER",
-    "ORCH_PLANE_BOT_DEPLOYER",
-    "ORCH_PLANE_BOT_STREAM",
-    "ORCH_GITEA_TOKEN",
-    "ORCH_TELEGRAM_BOT_TOKEN",
-    "ORCH_TELEGRAM_CHAT_ID",
-    "WATCHDOG_TG_BOT_TOKEN",
-    "WATCHDOG_TG_CHAT_ID",
-)
-
-# 32 байта энтропии -> 64 hex-символа (AC-5: >= 32 байт).
-TOKEN_BYTES = 32
-
-
-def generate_secret() -> str:
-    """Криптослучайный webhook-секрет: 32 байта энтропии, hex-кодировка."""
-    return secrets.token_hex(TOKEN_BYTES)
-
-
-def build_fragment() -> str:
-    """Собрать .env-фрагмент: свежие webhook-секреты + плейсхолдеры внешних.
-
-    Каждый вызов генерирует НОВЫЕ значения (secrets — CSPRNG); детерминизма нет
-    по построению (AC-5 «повторный запуск даёт другие значения»).
-    """
-    lines = [
-        "# --- ORCH-101 gen_secrets.py: НОВЫЙ комплект секретов этого хоста ---",
-        "# Сгенерировано локально; боевые секреты другого хоста сюда НЕ копируются.",
-        "# Webhook-секреты вписать также в настройки webhook'ов Plane/Gitea",
-        "# (см. docs/operations/REPLICATION.md и docs/operations/SETUP_WEBHOOKS.md).",
-    ]
-    for key in GENERATED_KEYS:
-        lines.append(f"{key}={generate_secret()}")
-    lines.append("# --- Внешние токены: выпустить по чек-листу REPLICATION.md ---")
-    for key in EXTERNAL_KEYS:
-        lines.append(f"{key}=")
-    return "\n".join(lines) + "\n"
-
-
-def main(argv: list[str] | None = None) -> int:
-    """CLI. Возвращает exit-код (0 ok; 2 — отказ перезаписи без --force)."""
-    parser = argparse.ArgumentParser(
-        description="Выпуск нового комплекта секретов оркестратора (ORCH-101)."
-    )
-    parser.add_argument(
-        "--write",
-        nargs="?",
-        const=".env",
-        default=None,
-        metavar="PATH",
-        help="записать фрагмент в файл (дефолт .env); существующий файл -> отказ",
-    )
-    parser.add_argument(
-        "--force",
-        action="store_true",
-        help="разрешить перезапись СУЩЕСТВУЮЩЕГО файла (явное подтверждение)",
-    )
-    args = parser.parse_args(argv)
-
-    fragment = build_fragment()
-
-    if args.write is None:
-        # Режим по умолчанию: только печать, файловая система не трогается.
-        sys.stdout.write(fragment)
-        return 0
-
-    path = args.write
-    if not args.force:
-        try:
-            # x-mode: атомарный «создать только если не существует» — никогда
-            # не перезаписывает существующий .env молча (NFR-3 / AC-5).
-            with open(path, "x", encoding="utf-8") as f:
-                f.write(fragment)
-        except FileExistsError:
-            sys.stderr.write(
-                f"ОТКАЗ: {path} уже существует — молча не перезаписываю. "
-                "Перезапись только с явным --force "
-                "(или укажи другой путь: --write PATH).\n"
-            )
-            return 2
-        except OSError as e:
-            sys.stderr.write(f"ОШИБКА записи {path}: {e}\n")
-            return 1
-    else:
-        try:
-            with open(path, "w", encoding="utf-8") as f:
-                f.write(fragment)
-        except OSError as e:
-            sys.stderr.write(f"ОШИБКА записи {path}: {e}\n")
-            return 1
-
-    sys.stderr.write(f"Записано: {path} (webhook-секреты сгенерированы заново)\n")
-    return 0
-
-
-if __name__ == "__main__":
-    sys.exit(main())

scripts/orchestrator-deploy-hook.sh

@@ -35,11 +35,7 @@
 
 set -euo pipefail
 
-# ORCH-101 (D7): env-override like every other variable of this hook. The wired
-# invokers (self_deploy.build_deploy_command / image_freshness.rebuild_staging_image)
-# pass REPO explicitly from ORCH_DEPLOY_HOST_REPO_PATH; the default below serves
-# manual operator runs on the current host.
-REPO="${REPO:-/home/slin/repos/orchestrator}"
+REPO=/home/slin/repos/orchestrator
 
 # ---- Defaults (STAGING — safe) ---------------------------------------------
 TARGET_SERVICE="${TARGET_SERVICE:-orchestrator-staging}"

src/agents/launcher.py

@@ -51,31 +51,6 @@ def is_valid_model(name: str) -> bool:
         return False
     return bool(_MODEL_NAME_RE.match(name.strip()))
 
-
-def agent_git_env() -> dict:
-    """ORCH-101 (A2): subprocess env for agent runs and their git commit/push.
-
-    HOME and the git identity are read from Settings (ORCH_AGENT_HOME_DIR /
-    ORCH_AGENT_GIT_NAME / ORCH_GIT_EMAIL_DOMAIN) instead of host hardcodes; the
-    defaults equal the previous production literals (/home/slin,
-    claude-bot@mva154.local), so an unset env is byte-for-byte the old
-    behaviour (BR-5 zero-regression). Single source for BOTH launch sites (the
-    agent Popen and the post-run git commit/push), so the two can never drift.
-    HOME must stay consistent with the compose mounts of .claude/.ssh
-    (ORCH-040 invariant — the same ORCH_AGENT_HOME_DIR interpolates the mount
-    targets in docker-compose.yml).
-    """
-    email = f"{settings.agent_git_name}@{settings.git_email_domain}"
-    return {
-        **os.environ,
-        "HOME": settings.agent_home_dir,
-        "GIT_AUTHOR_NAME": settings.agent_git_name,
-        "GIT_AUTHOR_EMAIL": email,
-        "GIT_COMMITTER_NAME": settings.agent_git_name,
-        "GIT_COMMITTER_EMAIL": email,
-    }
-
-
 # ORCH-061: action stages whose success is an ACTION (restart/retag), not a src
 # edit — so "no changes to commit" is EXPECTED there, not under-delivery (FR-3).
 _ACTION_STAGES = frozenset({"deploy-staging", "deploy"})
@@ -614,9 +589,14 @@ class AgentLauncher:
             ["bash", "-c", cmd],
             stdout=log_fh,
             stderr=subprocess.STDOUT,
-            # ORCH-101 (A2): HOME + git identity from Settings (defaults = the
-            # previous hardcoded values), shared with the post-run git env.
-            env=agent_git_env(),
+            env={
+                    **os.environ,
+                    "HOME": "/home/slin",
+                    "GIT_AUTHOR_NAME": "claude-bot",
+                    "GIT_AUTHOR_EMAIL": "claude-bot@mva154.local",
+                    "GIT_COMMITTER_NAME": "claude-bot",
+                    "GIT_COMMITTER_EMAIL": "claude-bot@mva154.local",
+                },
             )
 
         # Update DB with output path
@@ -840,8 +820,14 @@ class AgentLauncher:
         # (ensure_worktree did the checkout), so no checkout is needed here.
         repo_path = get_worktree_path(repo, branch)
         try:
-            # ORCH-101 (A2): same Settings-driven env as the agent Popen above.
-            git_env = agent_git_env()
+            git_env = {
+                **os.environ,
+                "HOME": "/home/slin",
+                "GIT_AUTHOR_NAME": "claude-bot",
+                "GIT_AUTHOR_EMAIL": "claude-bot@mva154.local",
+                "GIT_COMMITTER_NAME": "claude-bot",
+                "GIT_COMMITTER_EMAIL": "claude-bot@mva154.local",
+            }
             result = subprocess.run(
                 ["git", "-C", repo_path, "status", "--porcelain"],
                 capture_output=True, text=True, timeout=10, env=git_env

src/config.py

@@ -55,40 +55,6 @@ class Settings(BaseSettings):
     # DB
     db_path: str = "/app/data/orchestrator.db"
 
-    # ORCH-101 (replication foundation, ADR-001 D2/D4): host-parametrization keys.
-    # config.py is the ONLY legitimate home of host-specific literals in src/**
-    # (BR-1); every default below equals the current production value, so an
-    # absent/unchanged .env keeps behaviour byte-for-byte (BR-5, kill-switch
-    # nature — no extra flag is introduced, NFR-2).
-    #   agent_home_dir   -> HOME of every actor subprocess env (agent CLI Popen +
-    #                       git commit/push in agents/launcher, self-deploy
-    #                       finalizer, post-deploy monitor). The SAME env name is
-    #                       interpolated by docker-compose.yml as the target of
-    #                       the .claude/.claude.json/.ssh mounts and wired into
-    #                       Dockerfile ARG APP_HOME — one env name per fact (D1);
-    #                       the ORCH-040 uid/HOME/mounts group moves together.
-    #                       Env ORCH_AGENT_HOME_DIR.
-    #   agent_git_name   -> GIT_AUTHOR/COMMITTER_NAME of agent commits (the
-    #                       customer-visible identity). Env ORCH_AGENT_GIT_NAME.
-    #   git_email_domain -> domain of ALL actor git emails, built as
-    #                       f"{name}@{git_email_domain}"; name = agent_git_name
-    #                       for agents, and the PLATFORM literals
-    #                       deploy-finalizer / post-deploy-monitor for system
-    #                       actors (their names are not host-specific, D2).
-    #                       Env ORCH_GIT_EMAIL_DOMAIN.
-    #   staging_port     -> port of the staging instance (8501). Replaces the
-    #                       module constant image_freshness._STAGING_PORT; the
-    #                       SAME env name is interpolated into the staging
-    #                       compose `command:` so both readers see one fact (D1).
-    #                       Fail-closed guard in check_staging_image_fresh:
-    #                       staging_port == deploy_prod_target_port -> the
-    #                       freshness path REFUSES to run (ORCH-058 AC-9 made
-    #                       executable, D4). Env ORCH_STAGING_PORT.
-    agent_home_dir: str = "/home/slin"
-    agent_git_name: str = "claude-bot"
-    git_email_domain: str = "mva154.local"
-    staging_port: int = 8501
-
     # ORCH-1 (F-2b): persistent job queue / background worker.
     # max_concurrency  -> max agent jobs running in parallel (env ORCH_MAX_CONCURRENCY)
     # queue_poll_interval -> worker loop poll seconds (env ORCH_QUEUE_POLL_INTERVAL)

src/image_freshness.py

@@ -57,15 +57,8 @@ _REBUILD_TIMEOUT = 1200
 # the hook's staging-safe defaults but are passed EXPLICITLY so a future change to the
 # hook defaults can never silently retarget the self-rebuild at prod (8500) — the whole
 # path builds/recreates STAGING ONLY (AC-9, review P2). Never the prod 8500 target.
-# ORCH-101 (ADR-001 D4): the staging PORT moved to `settings.staging_port`
-# (env ORCH_STAGING_PORT, default 8501 — the same env name is interpolated into the
-# staging compose `command:`, one fact one name). The service/profile NAMES stay
-# platform constants: they are names of our own compose file (a tirage convention,
-# same logic as SELF_HOSTING_REPO / D3) — making them configurable could only
-# desynchronise the rebuild from compose within one repo. The ORCH-058 anti-prod
-# invariant is now an EXECUTABLE fail-closed guard in check_staging_image_fresh
-# (staging_port == prod port -> refuse loudly, never a silent 8501 fallback).
 _STAGING_SERVICE = "orchestrator-staging"
+_STAGING_PORT = 8501
 _STAGING_COMPOSE_PROFILE = "staging"
 
 
@@ -271,16 +264,12 @@ def rebuild_staging_image(repo: str, branch: str, sha: str) -> tuple[bool, str]:
     # rebuild + recreate + staging_check can never drift onto the prod 8500 service
     # even if the hook's defaults change (AC-9, review P2). STAGING_CONTAINER is the
     # container staging_check is docker-exec'd inside (step 3b).
-    # ORCH-101 (D7): REPO is passed EXPLICITLY (same source the `cd` below uses)
-    # — the hook's own default only serves manual operator runs; on the wired
-    # path the config is the single source of truth for the host repo path.
     env_assignments = (
-        f"REPO={shlex.quote(settings.deploy_host_repo_path)} "
         f"GIT_SHA={shlex.quote(sha)} "
         f"BUILD_CONTEXT={shlex.quote(host_ctx)} "
         f"TARGET_IMAGE={shlex.quote(settings.deploy_prod_source_image)} "
         f"TARGET_SERVICE={shlex.quote(_STAGING_SERVICE)} "
-        f"TARGET_PORT={shlex.quote(str(int(settings.staging_port)))} "
+        f"TARGET_PORT={shlex.quote(str(_STAGING_PORT))} "
         f"COMPOSE_PROFILE={shlex.quote(_STAGING_COMPOSE_PROFILE)} "
         f"STAGING_CONTAINER={shlex.quote(_STAGING_SERVICE)}"
     )
@@ -330,26 +319,6 @@ def check_staging_image_fresh(repo: str, work_item_id: str, branch: str) -> tupl
         if not image_freshness_applies(repo):
             return True, f"image-freshness N/A for {repo}"
 
-        # ORCH-101 (D4): fail-closed misconfiguration guard, BEFORE any
-        # ssh/build/recreate. The freshness path must NEVER be aimable at the
-        # prod target (ORCH-058 AC-9 / INV-FRESH) — with the port now a config
-        # key, the invariant is enforced here instead of implied by a constant.
-        # Deliberately NO silent fallback to 8501: a silent target substitution
-        # is exactly the failure class ORCH-058 was built against; the operator
-        # must fix the env (refuse loudly).
-        if int(settings.staging_port) == int(settings.deploy_prod_target_port):
-            reason = (
-                "misconfiguration: ORCH_STAGING_PORT == prod target port "
-                "(ORCH-058 AC-9) — staging rebuild refused"
-            )
-            logger.error("check_staging_image_fresh: %s", reason)
-            try:  # best-effort operator alert; never blocks the verdict
-                from .notifications import send_telegram
-                send_telegram(f"🚨 image-freshness [{repo}]: {reason}")
-            except Exception:  # noqa: BLE001 - alert is best-effort
-                pass
-            return False, reason
-
         sha = validated_revision(repo, branch)
         if not sha:
             # Fail-closed: without the validated commit we cannot prove freshness.

src/plane_sync.py

@@ -1060,15 +1060,8 @@ def notify_stage_change(work_item_id: str, old_stage: str, new_stage: str, agent
     if agent:
         msg += f" (launching {agent})"
 
-    # Add relevant links.
-    # ORCH-101 (A1): the link base and owner come from Settings — base is
-    # gitea_public_url with a gitea_url fallback (the exact semantics of the
-    # existing consumers notifications._build_brd_link / usage.py), owner is
-    # gitea_owner. No hardcoded host/owner in the executable path.
-    gitea_base = (
-        getattr(settings, "gitea_public_url", "") or getattr(settings, "gitea_url", "")
-    ).rstrip("/")
-    gitea_owner = getattr(settings, "gitea_owner", "")
+    # Add relevant links
+    gitea_base = "http://git.mva154.duckdns.org"
     try:
         from .db import get_db
         conn = get_db()
@@ -1078,9 +1071,10 @@ def notify_stage_change(work_item_id: str, old_stage: str, new_stage: str, agent
         conn.close()
         if row:
             branch, repo = row
-            msg += chr(10) + "📂 Branch: [" + branch + "](" + gitea_base + "/" + gitea_owner + "/" + repo + "/src/branch/" + branch + ")"
+            msg += chr(10) + "📂 Branch: [" + branch + "](" + gitea_base + "/admin/" + repo + "/src/branch/" + branch + ")"
             if new_stage in ("review", "testing", "deploy"):
                 import httpx as _httpx
+                from .config import settings
                 _headers = {"Authorization": f"token {settings.gitea_token}"}
                 _resp = _httpx.get(
                     f"{settings.gitea_url}/api/v1/repos/{settings.gitea_owner}/{repo}/pulls",
@@ -1091,7 +1085,7 @@ def notify_stage_change(work_item_id: str, old_stage: str, new_stage: str, agent
                     _prs = _resp.json()
                     if _prs:
                         pr_num = _prs[0]["number"]
-                        msg += chr(10) + "🔗 PR: [#" + str(pr_num) + "](" + gitea_base + "/" + gitea_owner + "/" + repo + "/pulls/" + str(pr_num) + ")"
+                        msg += chr(10) + "🔗 PR: [#" + str(pr_num) + "](" + gitea_base + "/admin/" + repo + "/pulls/" + str(pr_num) + ")"
     except Exception:
         pass