auto-sync: 2026-06-07 11:50:01

memory/2026-06-07.md

@@ -112,3 +112,40 @@ backward-compat при пустом EXPECTED_REVISION чтобы не слома
 **NB на будущее:** vibecode-баланс может кончиться молча → Dev-спавн падает на старте.
 Проверять модель/баланс при спавне Dev-агента. Фолбэк-модели с балансом: tokenator
 (opus/sonnet), anthropic напрямую, GLM, DeepSeek.
+
+
+## ORCH-58 — retag-фикс ДОЖАТ (вечер 07.06, обновление)
+
+Путь B сработал. **Dev-агент на `tokenator/claude-opus-4-8` довёл реализацию** (предыдущий
+на vibecode/claude-sonnet-4.6 упал на старте — кончились кредиты, см. выше; opus 4.8 имел
+баланс → `modelApplied: true`).
+
+**Что внёс Dev (коммит `f0c2986`, запушен в `feature/ORCH-058-self-deploy-retag-staging`):**
+- `scripts/orchestrator-deploy-hook.sh` (+27): объявления `REVISION_LABEL=org.opencontainers.image.revision`,
+  `EXPECTED_REVISION="${EXPECTED_REVISION:-}"`; fail-closed provenance guard ВНУТРИ
+  `if [[ -n "$SOURCE_IMAGE" ]]` ПЕРЕД `docker tag` (инспект label → нормализ `<no value>` →
+  `[[ -z "$IMG_REV" || "$IMG_REV" != "$EXPECTED_REVISION" ]]` → exit 1); весь guard обёрнут
+  в `if [[ -n "$EXPECTED_REVISION" ]]` → пустой = пропуск (backward-compat для ORCH-36);
+  новый режим `--build-staging` (`GIT_SHA=$(git rev-parse HEAD)` + `docker build --build-arg GIT_SHA`).
+- `Dockerfile` (+4 после WORKDIR): `ARG GIT_SHA` + `LABEL org.opencontainers.image.revision=$GIT_SHA`.
+- Заминка окружения: ветка «залипла» на stale-worktree `/repos/_wt/...` (физически отсутствовал)
+  → `git worktree prune` + checkout в основном репо. Тесты НЕ переписаны, чужой python не тронут.
+
+**Проверка (моя независимая + Dev):** 4 целевых теста PASSED; полный прогон **627 passed**
+(на хосте git есть → test_git_worktree/test_merge_gate тоже зелёные, не 614); **CI ветки `success`**
+(был `failure`). grep: guard/режим 11 совпадений, Dockerfile 2. Реальный код.
+
+**Нюанс возврата в конвейер:** мой ре-триггер (flip In Review→Approved/двиг stage) конвейер
+понял как «Needs Input answered» → **перезапустил СВОЕГО конвейерного developer** (job 207,
+run_id=265) поверх уже зелёной ветки, вместо прямой gate-перепроверки. Не страшно (ветка
+зелёная, конвейерный дев увидит готовое), но УРОК: **возврат задачи в конвейер через In
+Progress = relaunch developer-агента, а не просто re-check gate.** Если надо только
+перепроверить gate без нового dev-прохода — искать другой механизм (не flip через In Progress).
+
+**Статус на конец сессии:** ORCH-58 в конвейере, job 207 running (догоняет штатно).
+Дальше сам: dev-gate (CI зелёный → пройдёт) → Review → Testing → merge-gate → **deploy**.
+На deploy-стадии нужен **апрув Славы** (как ORCH-36) — дёрнуть его.
+
+**УРОК про Dev-агента:** конвейерный developer склонен к недожиму (написал тесты, не
+дописал реализацию — TDD без доводки). Прямой Dev-агент с УЗКИМ ТЗ (точные строки, готовые
+тесты как спека) надёжнее для доводки. Но финал мержа/деплоя — всё равно через конвейер с гейтами.