auto-sync: 2026-06-05 19:40:01

This commit is contained in:
Stream
2026-06-05 19:40:01 +03:00
parent 87419a4014
commit 975abec723

View File

@@ -581,3 +581,80 @@ Dev (session orch9_docs_canon) отработал, я проверила не с
### Урок: CI-гейт был дырявым на самой важной логике
- Две дыры в одном месте: (а) красные тесты пропускались, (б) async-тесты скипались из-за отсутствия pytest-asyncio. Оба светили зелёным CI. Для self-hosting честный гейт качества критичен — теперь закрыто в PR #35.
---
## 🏁 ФИНАЛ ДНЯ (05.06 вечер) — ORCH-16 в проде, ET-11 self-driving, ORCH-41 конфигурируемые модели
### ✅ ORCH-39 + ORCH-16 ВЫКАЧЕНЫ В ПРОД
- PR #35 (ORCH-39, тесты+CI) смержен (`f375be24`, 342 passed).
- PR #34 (ORCH-16, единый формат коммента) rebase на main → 402 passed → смержен (`8da571d`).
- Прод ребилжен из main: `build_status_comment`×9, `frontmatter.py` в контейнере, `.env` цел (23 строки), очередь чистая.
- **ORCH-39 → Done** (PATCH HTTP 200). ⚠️ Способ выполнения Plane-PATCH из контейнера: скрипт `/tmp/fix39.py``docker cp` в `orchestrator:/tmp/``docker exec orchestrator python3`. Вложенные `os.popen` внутри python-однострочника ломаются на экранировании (`printenv ... not found`) — НЕ делать, использовать heredoc+docker cp.
### ✅ ORCH-40 заведена (Backlog, id `cec9a5ef`) — фикс root-прав deployer
- Контейнер orchestrator работает под uid=0(root) → агенты пишут root-файлы в смонтированный хост-репо → ломает git под slin. При ребилде чинила руками (`chown -R slin` + `git reset --hard` + clean). Корневой фикс отложен (трогает рантайм агентов, выше риск).
### ✅ АУДИТ БЭКЛОГА ORCH (обратный рассинхрон — НЕ найден, Done честные)
Проверила материально 14 «Done»-задач на проде (файл/контейнер/таблица/эндпоинт, не по статусу):
- ORCH-16 (build_status_comment ×9 + frontmatter.py в контейнере) ✅
- ORCH-1 (таблица `jobs`, `/queue` живой) ✅
- ORCH-2 (git_worktree.py, worktree enduro+orchestrator) ✅
- ORCH-6 (projects.py, plane_project_id ×10) ✅
- ORCH-31 (контейнер orchestrator-staging Up) ✅
- ORCH-29 (PRODUCT_VISION.md + .pptx) ✅
- ORCH-34/35/36 (deploy-hook.log 18.9KB) ✅
- ⚠️ **ORCH-36 нюанс (не баг статуса):** числится Done «исполняемый самодеплой», но при ребилде ORCH-16 катила прод РУКАМИ. deploy-hook.log есть → механизм есть, но автоматизм self-deploy орка-на-себя стоит перепроверить при случае. Не срочно.
- **Итог:** 40 задач = 25 Backlog, 15 Done. Все Done подтверждены материально. ORCH-39 поправлена Backlog→Done.
### 🎉🎉 ET-11 — ПЕРВЫЙ ПОЛНЫЙ SELF-DRIVING ET-ЗАДАЧИ ЧЕРЕЗ ОРК НА ЖИВОМ ПРОДЕ
- ET-11 = «Healthcheck enduro-trails-app падает: в контейнере нет curl (ложный unhealthy)» (id `e60715d4`, work_item ET-015).
- **Диагноз (мой, лично):** healthcheck = `curl -f localhost:5556/api/health`, но в контейнере **нет ни curl, ни wget** (образ голый, только python) → healthcheck ВСЕГДА fail, FailingStreak **3762**. Само приложение здоровое (HTTP 200/7мс, живой трафик, RestartCount=0). Ложная тревога 31 час.
- **Конвейер прошёл ВЕСЬ цикл сам:** analysis→architecture→development→review→testing→deploy→done. На гейте Approved **остановился и дождался Славы** (Слава заапрувил вручную в 15:17 — человек-в-петле сработал штатно, НЕ автопроскок).
- **РЕАЛЬНО ПОЧИНИЛ БАГ НА ПРОДЕ:** PR #30 «use python urllib for container healthcheck» (заменили отсутствующий curl на python — ровно как я закладывала в ET-11). Смержен. PR #31 deploy (tag v0.0.7) смержен.
- **Результат на живом проде:** контейнер `enduro-trails-app-1` теперь **`Up (healthy)`**, FailingStreak **0** (было 3762), HTTP 200/4мс. Прод НЕ упал даже без staging у ET.
- **Боевая обкатка ORCH-16:** все агенты постили комменты единого формата (в логе `comment added to ET-015 author=deployer` ×2). Фича единого коммента работает в бою.
- ⚠️ Риск был реальный: у ET НЕТ staging → deployer катил в живой прод 5556. Обошлось, но на будущее — для рискованных ET-задач держать стоп-флаг на deploy.
### ✅ ORCH-41 — КОНФИГУРИРУЕМЫЕ МОДЕЛИ + EFFORT per-agent + per-project (фундамент мультипровайдеров ORCH-13)
**Задача Славы:** «модель выбирается в настройках, под каждого агента, с per-project override. Сделать сейчас.»
**КОРЕНЬ почему агенты были на Opus 4.7 (разобрала лично, по боевым логам):**
- `src/agents/launcher.py` AGENT_CONFIGS: architect/reviewer → `"model": "opus"` (алиас!), остальные — модели НЕТ (CLI-дефолт).
- **Алиас `opus` в CLI 2.1.142 резолвится в `claude-opus-4-7`** (НЕ обновился на 4.8 авто). Подтверждено `runs/102.log`, `runs/103.log` → реально летит `claude-opus-4-7`.
- **4.8 доступна** — проверила прямым вызовом: `claude-opus-4-8` / `opus-4-8` / `claude-opus-4-8-20250930` все `subtype: success`. CLI+аккаунт поддерживают, просто алиас не привязан.
**Режимы работы CLI 2.1.142 (разведано, для будущего):**
- `--effort low|medium|high|xhigh|max` — ⭐ ГЛАВНЫЙ рычаг «качество vs стоимость» (аналог reasoning-бюджета). Раз 4.7=4.8 по цене, effort важнее версии.
- `--model` (алиас/полное имя), `--fallback-model` (автофолбэк при overloaded, работает с `--print`), `--permission-mode` (acceptEdits/auto/bypassPermissions/plan/dontAsk), `--bare` (без хуков/LSP/memory).
**Реализация (Dev, PR #36 `feat/ORCH-41-agent-models`, проверено мной лично):**
- `src/config.py` Settings: `agent_model_default` (дефолт `claude-opus-4-8`), `agent_model_<agent>` + `agent_effort_<agent>` (env `ORCH_AGENT_MODEL_*`, `ORCH_AGENT_EFFORT_*`). Паттерн как `plane_bot_*`.
- `src/projects.py` ProjectConfig: поля `agent_models` + `agent_efforts` (dict, `field(default_factory=dict)` — frozen dataclass!), парсятся из projects_json (опционально).
- `resolve_agent_model/effort` — приоритет: **per-project → env per-agent → default → CLI-дефолт**.
- launcher.py: убран хардкод `"model":"opus"`, модель+effort резолвятся.
- **Раскладка effort (согласовано Славой):** думающие (analyst/architect/developer/reviewer) → **high**, механические (tester/deployer) → **medium**.
- **Дефолт модели = `claude-opus-4-8`** (Слава: «4.8 и 4.7 стоят одинаково, по дефолту 4.8»).
- **Проверено лично на проде:** 423 passed (402+21), off-limits (gates/webhook/HMAC/queue) НЕ тронуты, резолвинг вживую: analyst/developer→opus-4-8/high, tester/deployer→opus-4-8/medium. Хардкод `opus` убран.
- **PR #36 — Слава дал ОК на мерж (последнее сообщение), мерж+ребилд ещё НЕ выполнены на момент флаша.** После мержа: ребилд прода (учесть грабли root-прав ORCH-40), чтобы агенты реально поехали на 4.8/effort. Реальное переключение env прода — осознанно, с оглядкой на бюджет ORCH-38.
### НОВЫЕ ORCH-ЗАДАЧИ дня:
- **ORCH-40** (id `cec9a5ef`) — фикс root-прав deployer, Backlog.
- **ORCH-41** (id `17f9a73f`) — конфигурируемые модели per-agent, в работе → PR #36 готов, ждёт мержа.
- **ET-11** (id `e60715d4`) — healthcheck curl, ✅ Done через конвейер (исправлено на проде, v0.0.7).
### КЛЮЧЕВЫЕ УРОКИ дня:
- **launcher.py model был алиасом `opus`** → CLI резолвил в 4.7. Конфигурируемость (env+per-project) — правильное решение вместо хардкода версии.
- **effort = главный рычаг цены/качества** при равной цене версий модели.
- **Plane-PATCH из контейнера:** скрипт-файл + docker cp + docker exec, НЕ вложенные os.popen.
- **Зеркало `/repos/orchestrator` отстаёт от Gitea** — источник истины при мерже = Gitea API, не локальный клон.
- **PR #34 мержить squash через Gitea, не force-push rebase** (чище, mergeable=True).
- **Человек-в-петле (гейт Approved) работает штатно** — ET-11 встала, дождалась ОК Славы, поехала. Не автопроскок.
- Per-project state UUID (повтор для надёжности): ET in_progress `b873d9eb`, approved `a519a341`, rejected `ba958f3c`; ORCH in_progress `e331bfb3`, approved `63f2c8fe`, rejected `4c769e90`.
### Артефакты дня:
- ТЗ ORCH-41: `tasks/orchestrator/DEV_TASK_ORCH41_AGENT_MODELS.md`
- ТЗ ORCH-39: `tasks/orchestrator/DEV_TASK_ORCH39_FIX_WEBHOOK_TESTS.md`
- Отчёт ORCH-39: `tasks/orchestrator/reports/dev-2026-06-05-orch39-webhook-tests.md`
- main HEAD после PR #34: `8da571d`. PR #36 (ORCH-41) — open, ждёт мержа.