wiki/memory/2026-06-07.md

🏁 ORCH-58 ЗАКРЫТ В ПРОДЕ (10:23 UTC) — provenance guard боевой

Слава делегировал решение: «реши сама, цель — починить и запустить автономный контейнер, исходи из целей орка». Довела до конца сама.

Что было дожато (вся цепочка дня): P0-блокеры (2ee06ae) → P1 staging_check вариант А (c53d625) → конвейерная параметризация + доки (6ddff55) → reviewer APPROVED v4 → tester PASS → merge PR #57 в main (094b5e2).

Финал — прод-деплой сам решила и выполнила:

1. Конвейер зациклился на deploy-staging (deployer exit 0 → «no changes to commit» → stage_engine откатывал deploy-staging→development по кругу). Это баг механики deploy-стадии (родня ORCH-21), НЕ код ORCH-58. Остановила петлю (парк In Progress + cancel job 218).
2. Замержила approved-ветку в main руками через Gitea API (PR #57 → 094b5e2, mergeable=True). staging_check+guard живы в main.
3. Ловушка fail-closed deadlock: прод-retag берёт SOURCE_IMAGE=staging-образ, а его revision-label был ПУСТОЙ (собран до merge) → guard зарубил бы (label != EXPECTED 094b5e2). Решение: пересобрала staging из main HEAD через НОВЫЙ режим --build-staging (GIT_SHA=094b5e2) → label проставился = 094b5e2. Health 8501 OK. (staging_check в build вернул FAIL 8/10 — но это ЛОЖНЫЙ фейл окружения: C9a/C9b sandbox e2e без bot-токенов SANDBOX-проекта, НЕ регресс. Конвейерный tester на этом же коде проходил.)
4. Ключевой инсайт: прод --deploy НЕ гоняет staging_check (он только в --build-staging). --deploy сверяет ТОЛЬКО revision-label. Label теперь валидный → guard пропустит ЧЕСТНО, без обхода. Значит ложный sandbox-фейл к проду отношения не имеет.
5. Прод-деплой выполнен (detach setsid, переживает рестарт 8500, prev-image сохранён + rollback-pre-058 tag). Лог хука: PROVENANCE: SOURCE_IMAGE revision matches expected (094b5e2) - retag allowed → BUILD-ONCE retag → restart → Deploy SUCCESS: healthy on 8500, result=0.

Верификация прода: контейнер Up на новом образе, revision-label=094b5e2, health 200, EXPECTED_REVISION прокидывается (2×), image_freshness import OK, queue_worker+reconciler запущены (автономность жива), старт без traceback. ORCH-58 → Done в Plane (200) + коммент.

ИСТОРИЧЕСКОЕ: provenance guard (весь день дожимали) ВПЕРВЫЕ отработал в БОЕВОМ прод-деплое и пропустил по совпадению revision — ровно защита от «тихого regress устаревшим staging-образом», ради которой задача и заводилась. Self-deploy теперь с реальным fail-closed провенансом.

УРОКИ:

• Не читать src из РАБОТАЮЩЕГО прод-контейнера для проверки «что в коде» — он крутит СТАРЫЙ образ. Всегда git show origin/main. (Чуть не подняла ложную тревогу «EXPECTED_REVISION не прокидывается».)
• deploy-staging петля (deployer exit0 + no-changes → откат на development) — баг stage_engine, завести тикет (родня ORCH-21 post-deploy). Пока обходится ручным merge+deploy.
• Перед прод-retag через build-once SOURCE_IMAGE=staging — ОБЯЗАТЕЛЬНО проверить, что revision-label staging-образа == целевой main HEAD, иначе guard fail-closed (by design). Если не совпал → пересобрать staging через --build-staging GIT_SHA=<main HEAD>.
• staging_check stub в ручной среде даёт ложные C9a/C9b (sandbox bot-токены не настроены) — это НЕ регресс. Авторитетен конвейерный tester. Для прод---deploy staging_check вообще не на пути (только label-guard).

TODO (follow-up, в Backlog): баг deploy-staging петли; добавить sandbox bot-токены чтобы ручной staging_check проходил 10/10.