wiki/memory/2026-06-10.md

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. Аналитик увидит свежую версию.