19 lines
4.0 KiB
Markdown
19 lines
4.0 KiB
Markdown
# 2026-06-10
|
||
|
||
## ✅ ORCH-100 (F1b sidecar-watchdog) BRD APPROVED (Слава: «проверь и если ок подтверждай», 05:41 UTC)
|
||
- Первая задача эпика саморазвития, прошедшая аналитику. BRD/ТЗ/AC — ЭТАЛОН.
|
||
- **Аналитик ПРОЧИТАЛ концепцию из репо** (docs/epics/self-evolution.md) и идеально усвоил архрамки: C-1 sidecar отдельный контейнер / код в репо watchdog/ / C-2 без плеча / C-3 тонкий не-Grafana / свой Telegram-канал / read-only docker.sock / орк-down=тревога. → подтвердило: класть концепцию в репо было правильным решением.
|
||
- **Верифицировала кодом (урок дня):**
|
||
- F1a /metrics РЕАЛЬНО в проде (ORCH-099 done, HTTP 200, конверт schema_version:1/generated_at/clk_tck:100/stages/queue/agents/cost — точно как в ТЗ). Контракт под F1b работает. ✅
|
||
- disk_watchdog.decide_action (src:105) — образец решающей функции реален (ТЗ звал 'decide', факт 'decide_action' — по сути верно). ✅
|
||
- watchdog/ папки ещё нет — верно, F1b создаёт. ✅
|
||
- Аналитик грамотно: анти-дубль диск-алерта с ORCH-063 (BR-10/FR-9/AC-5, тонкость!), вынес в зону архитектора стек Python/Go + владельца диск-алерта + mem_limit + топологию сети. 14 TC, 7 AC.
|
||
- Закрыла brd-clock → Approved (200) → architect job 1526 running, stage=architecture, ветка feature/ORCH-100-fnd-f1b-sidecar-watchdog. autoApprove? нет — был ручной approve Славы (на 100 не вешали autoApprove, только запускали F1a в авто). Идёт автономно дальше (autoDeploy если был навешен).
|
||
|
||
## 🎯 Концепция: скоуп наблюдения (3 слоя) + атрибуция уроков (Слава 10.06 06:01)
|
||
- **Вопрос Славы:** F1a/F1b мониторят только орк, или проекты (ET-контейнер) тоже? + саморазвитие может катить ET: фича в ET деградировала ET — это орк недоработал процесс или в ET усилить тесты?
|
||
- **Вписала в концепцию (docs/epics/self-evolution.md, обновлён в репо):**
|
||
- **Скоп наблюдения 3 слоя:** Слой1 проекты как ЗАДАЧИ в конвейере (ET в /metrics stages) — ✅ в скопе F1a/F1b (здоровье конвейера). Слой2 проекты как КОНТЕЙНЕРЫ на хосте (enduro-app через docker.sock) — ✅ в скопе F1b (жив/мёртв, общий хост впритык). Слой3 ВНУТРЕННЕЕ бизнес-здоровье продукта (эндпоинты ET 200? latency?) — ❌ НЕ фундамент, это мониторинг ПРОДУКТА = будущая фича D4/D5 (per-project health, опция заказчику).
|
||
- **Атрибуция уроков (новый шаг петли 8A):** деградация продукта после фичи → петля различает: А) platform-level (орк недоработал ПРОЦЕСС — нет регресс-гейта/перф-бенчмарка → чинить в D1/D2, польза ВСЕМ) vs Б) project-level (в ET мало тестов → усилить тесты в бэклоге ET, польза только ET). Бывает ОБА. Без слоя-3 детекции петле нечего атрибутировать → слой3 нужен и петле, не только заказчику. E2-ретроспективщик несёт классификацию, спорное → Стрим/Слава.
|
||
- Commit в main. Аналитик увидит свежую версию.
|