auto-sync: 2026-06-08 22:20:01

memory/2026-06-08.md

@@ -343,3 +343,14 @@
 - Диагностика: `notifications.py` — оба вызова (`sendMessage` трекера + `editMessageText`) без `disable_web_page_preview`. Фикс = добавить `"disable_web_page_preview": True` в payload обоих. Ссылка остаётся кликабельной.
 - **Решение Славы: вариант 1** — отдельная микро-задача орка (чисто через конвейер, не руками в репо — урок ORCH-26/71).
 - Создана **ORCH seq=80** id=088946c2-e709-419b-8591-f0a15b5b61fd, в **Backlog** (НЕ запущена — webhook на Backlog не триггерит). LOW. AC-1..4. Зависимость: один репо с orch-74 → запускать ПОСЛЕ её мержа (сериализация ORCH-26).
+
+## 🎉 ORCH-52a (orch-74) В ПРОДЕ — мёртвый frontmatter убран + валидация модели (08.06 ~19:11 UTC)
+- Слава: «проверяй все и переводи на деплой». Прошла весь конвейер автономно (analyst×2 = 1 REQUEST_CHANGES BRD-цикл → architect→dev→review APPROVED→test PASS→staging SUCCESS).
+- **Проверила код своими глазами (не только вердикты):** AC-1 `model:` убран из всех 6 `.openclaw/agents/*.md` (grep пусто, остался name/description/tools); AC-2 `is_valid_model()` валидирует ИМЯ ДО `--model`, never-break (garbage/'' → False → откат на default), fallback тоже; 32 теста passed; ADR-001 написан. Все 6 агентов → claude-opus-4-8 (G3 routing НЕ тронут, как решил Слава).
+- ⚠️ **ПОПУТНАЯ НАХОДКА (НЕ регрессия 74, НЕ блокер):** эффорт в проде резолвится в `''` (пусто) для ВСЕХ агентов! config defaults заданы (high/medium), НО env `ORCH_AGENT_EFFORT_*` в проде = ПУСТАЯ строка → перебивают config → агенты на CLI-дефолте эффорта, не на high/medium. ТЗ «эффорт уже настроен» верно по коду, неверно по факту прода. → **TODO: отдельная задача — убрать пустые ORCH_AGENT_EFFORT_* из env (или выставить high/medium), чтобы эффорт Opus 4.8 реально работал.**
+- 🔒 **СРАБОТАЛА ЗАЩИТА ORCH-73 (fail-closed):** первый финал `merge_pr -> ok=False (no open PR)` → задача УДЕРЖАНА на deploy (НЕ done), Plane→Blocked. Причина: конвейер НЕ создал PR для ветки. НЕ ложно-зелёный — защита отработала идеально.
+- **Фикс штатный (НЕ ручной reset):** создала PR #79 через Gitea API (mergeable=True) → перезапустила `run_deploy_finalizer` штатно → merge_pr честный. **PR #79 merged=True, merge_commit a091a2d = новый origin/main, код 0873803 РЕАЛЬНО в main** (ancestor=YES), model: в main=0. Задача → done. Прод на новом коде: is_valid_model есть, все 6 → opus-4-8.
+- ⚠️ **ГРАБЛИ (новые, разобрать):** (1) конвейер НЕ создал PR для ветки ORCH-074 (обычно PR на reviewer/deployer) — возможно системный пробел, не разовый. (2) ручной INSERT job 590 не подхватился queue_worker'ом (не хватило claim-поля) → пришлось run_deploy_finalizer напрямую.
+- **Обе находки заведены задачами (Слава: «заводи обе»), Backlog, НЕ запущены:**
+  - **ORCH-52h (seq=81)** id=ccfdf129-81f2-4549-a0a9-e0b2e1515c78 — эффорт резолвится в '' (env перебивает config). HIGH. AC-1..5, реком. вариант (c): пустая строка эффорта → откат на default. Часть эпика ORCH-52.
+  - **ORCH-81 (seq=82)** id=d836b313-6ca0-483a-926b-f09fc33fc140 — конвейер не создаёт PR → HOLD на merge-verify. HIGH (блокирует автономный деплой). AC-1..6, G1 root-cause → G2 гарантия PR (идемпотентно) → G3 логи. Защита ORCH-73 НЕ ослаблять. ⚠️ подозрение на системный пробел.