claude-bot
01684a89df
The staging-image rebuild (check_staging_image_fresh, ORCH-058) uses the task git worktree as the docker build context. `data/` is gitignored (runtime SQLite DB + backups) so it is absent in every worktree -> `COPY data/ ./data/` failed the build (rc=1) -> deploy-staging rolled back to development (the loop ORCH-061 targets, surfaced one step later once the C9a/C9b waiver let the pipeline reach the rebuild). The DB always arrives via the compose bind mount, so baking it in was pointless (and leaked a stale host DB into the image). Replace `COPY data/ ./data/` with `RUN mkdir -p /app/data` and add a static regression guard asserting the Dockerfile never COPYs a gitignored path. Refs: ORCH-061 Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
27 lines
6.0 KiB
Markdown
27 lines
6.0 KiB
Markdown
# 10 — Технические риски: ORCH-061
|
||
|
||
Work Item: **ORCH-061** · Репо: `orchestrator` (self-hosting)
|
||
|
||
| # | Риск | Вероятн. | Влияние | Митигация |
|
||
|---|------|----------|---------|-----------|
|
||
| **R-1** | Waiver C9a/C9b маскирует **реальный** регресс именно в создании ветки / постановке analyst-job (ложно-зелёный staging). | Низкая | Высокое | Allowlist жёстко `{C9a, C9b}`; waiver применяется ТОЛЬКО когда ВСЕ REAL-проверки зелёные, включая C7 (создать issue) и C8 (триггер `/webhook/plane`) — вход в конвейер всегда валидируется реально. `INFRA-WAIVED`-строка в логе/комменте делает допущение видимым (FR-7). Honest 10/10 (IR-2) убирает риск совсем. |
|
||
| **R-2** | Ослабление страховки: реальный pipeline-FAIL пройдёт как SUCCESS. | Низкая | Критич. | Инвариант `compute_staging_verdict`: любая упавшая REAL → exit1 → FAILED → откат (FR-4/AC-3/TC-05). Покрыто юнит-тестом отдельным кейсом. |
|
||
| **R-3** | Флаг не достигает скрипта (читается не из того env) → толерантность «молча» не работает или, наоборот, не выключается. | Средняя | Среднее | Скрипт читает `settings.staging_infra_tolerance_enabled` через `from src.config import settings` — тот же канал, что B6/ORCH-048 (внутри `orchestrator-staging`, env `.env.staging`). На ошибке импорта — fail-safe в strict (False) + warning. Документировать ключ в `.env.staging`/`.env.example` (IR-1). Тест kill-switch (TC-09). |
|
||
| **R-4** | Классификатор ошибочно пометит REAL-проверку как SANDBOX_INFRA (расширение allowlist в будущем). | Низкая | Высокое | `classify_check` — узкий префиксный allowlist; добавление новой инфра-метки требует осознанного PR + теста (TC-03). По умолчанию неизвестная метка → REAL (консервативно). |
|
||
| **R-5** | Регресс совместимости: изменение exit-code suite ломает другие потребители (deploy-хук, ручные прогоны). | Низкая | Среднее | Exit-code семантика сохранена для honest-прогонов (всё PASS → 0; реальный FAIL → 1). Меняется лишь трактовка «только инфра-FAIL» (теперь 0 при толерантности). Deployer-маппинг exit0→SUCCESS/≠0→FAILED не меняется; deployer.md уточняется. `--strict` даёт ручной honest-режим. |
|
||
| **R-6** | never-raise нарушен: исключение из `staging_verdict`/классификатора. | Низкая | Среднее | `src/staging_verdict.py` — pure, без I/O; контракт never-raise (на битом вводе → консервативный FAILED). Логика вне пути `advance_stage` (исполняется в subprocess suite), поэтому в конвейер исключение структурно не попадает (AC-10). |
|
||
| **R-7** | FR-3: правка no-changes протекает на code-стадию (`development`) и маскирует «developer ничего не сделал». | Низкая | Среднее | Observability-строка ограничена `stage ∈ {deploy-staging, deploy}` и `self_deploy_applies(repo)`; логика продвижения launcher не меняется. Regression-guard TC-07. |
|
||
| **R-8** | Self-hosting: правки случайно затронут прод 8500 / не-self репо. | Низкая | Критич. | Изменения только на self-deploy-пути и в suite (бежит лишь для `orchestrator`-staging). `check_staging_status` для не-self репо неизменно `(True, N/A)` (AC-6/TC-08). Сборки/recreate — только 8501. Прод 8500 не трогается (AC-12). |
|
||
| **R-9** (realized) | Та же петля `deploy-staging → development` по ВТОРОЙ причине: `docker build` staging-образа падает (rc=1), т.к. `Dockerfile` `COPY data/ ./data/` ссылается на gitignore-каталог, отсутствующий в build-context воркти. Всплыло, когда waiver C9a/C9b впервые пропустил конвейер до пересборки образа (`check_staging_image_fresh`, ORCH-058). | — (произошло) | Высокое | `COPY data/ ./data/` → `RUN mkdir -p /app/data`. `data/` приходит через compose bind-mount, в образ запекать нечего. Инвариант: `Dockerfile` не `COPY` gitignore-путей (иначе сборка из воркти ломается). Гард — `tests/test_dockerfile_worktree_buildable.py`. |
|
||
|
||
## Контрактные инварианты (не нарушать)
|
||
- `STAGE_TRANSITIONS`, `get_previous_stage` — без изменений.
|
||
- Реестр `QG_CHECKS` — без изменений; новый QG-чек НЕ вводится (снапшот-тест зелёный, TC-11).
|
||
- Frontmatter `staging_status:` / `deploy_status:` — только YAML, `SUCCESS|FAILED`.
|
||
- Exit-code хука деплоя (0/1/2) и `map_exit_code_to_status` — без изменений.
|
||
- БАГ-8 (`deploy → development`) и ORCH-35 (`deploy-staging → development`) для
|
||
**реальных** провалов — сохранены.
|
||
- Схема БД — без миграций.
|
||
# ci-rerun 2026-06-07T13:08:38Z after disk cleanup
|
||
# ci-rerun gitea-restarted 2026-06-07T13:14:14Z
|