diff --git a/memory/2026-06-10.md b/memory/2026-06-10.md index 167e087..aa433a7 100644 --- a/memory/2026-06-10.md +++ b/memory/2026-06-10.md @@ -9,3 +9,10 @@ - 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. Аналитик увидит свежую версию. diff --git a/tasks/orchestrator/EPIC_AUTONOMOUS_SELF_EVOLUTION.md b/tasks/orchestrator/EPIC_AUTONOMOUS_SELF_EVOLUTION.md index dee19f7..78b5f51 100644 --- a/tasks/orchestrator/EPIC_AUTONOMOUS_SELF_EVOLUTION.md +++ b/tasks/orchestrator/EPIC_AUTONOMOUS_SELF_EVOLUTION.md @@ -75,6 +75,16 @@ - **F1 Наблюдаемость** (ORCH-83 [ЭПИК]): метрики agent-liveness + очередь + стадии + хост (диск/память/CPU) + контейнеры + внешние деп (Plane/Gitea/Anthropic). Эндпоинты /health /status /queue → расширить до /metrics + дашборд. - **F2 Журнал уроков** (ORCH-8 шаг 1): машинная структурированная таблица отклонений (тип, контекст, корень, предложение, статус) — формализовать то, что сейчас в memory/. Это «топливо» для вертикали-двигателя. +### 🎯 СКОП НАБЛЮДЕНИЯ — три слоя (решено Славой 10.06) + +> Граница «мониторим ПЛАТФОРМУ vs ПРОДУКТЫ на ней». Важно для архитектора и будущих задач — не путать уровни. + +- **Слой 1 — проекты как ЗАДАЧИ в конвейере — ✅ В СКОПЕ (F1a/F1b).** ET-задачи в stages/queue/agents `/metrics` — это работа орка (его агенты/очередь/стадии). Sidecar алертит «ET-задача застряла». Здоровье КОНВЕЙЕРА. +- **Слой 2 — проекты как КОНТЕЙНЕРЫ на хосте — ✅ В СКОПЕ (F1b, жив/мёртв).** `enduro-trails-app-1`, `osrm` и пр. через docker.sock ro — Up/healthy/restarting/exited. Общий хост впритык → текущий ET-контейнер вредит орку. Здоровье контейнера как чёрного ящика. +- **Слой 3 — ВНУТРЕННЕЕ бизнес-здоровье продукта — ❌ НЕ В ФУНДАМЕНТЕ, НО НУЖНО (см. ниже).** Эндпоинты ET отвечают 200? карта рендерится? latency не деградировала после фичи? Орк не знает внутренностей задеплоенных приложений — это МОНИТОРИНГ ПРОДУКТА, не платформы. + +**Слой 3 — это отдельная продуктовая способность (домен D4/D5):** «per-project мониторинг здоровья задеплоенного приложения» — опция для заказчика («слежу, что твой ET-сайт жив»). **НО он НУЖЕН и самой петле** (см. §8A «атрибуция уроков») — без детекции деградации продукта петле нечего ловить. Порядок: фундамент (слои 1-2) сначала, слой 3 — позже как D4/D5-фича. + --- ## 3. ДОМЕН D1 — 🛡️ Надёжность (Self-Repairing) @@ -166,6 +176,25 @@ - **Анализ (гибрид):** машина копит и предлагает черновик → Стрим фильтрует/оформляет → Слава апрувит. - **E1** Журнал уроков (=F2). **E2** Агент-ретроспективщик (анализ→предложение). +#### ⚖️ АТРИБУЦИЯ урока — platform-level vs project-level (решено Славой 10.06) + +> Ключевой шаг петли. Пример Славы: выпустили фичу в ET → она деградировала ET. Петля поймала сигнал — но ЧЬЯ вина и ГДЕ чинить? + +Когда детектирована деградация продукта после выпуска фичи, петля ДОЛЖНА различить два уровня вины и направить урок в правильное русло: + +- **А. Platform-level (недоработал ОРК):** конвейер выпустил деградацию, потому что у платформы СЛАБЫЙ ПРОЦЕСС (нет регресс-гейта «фича не ломает соседнее», тест-стадия не ловит деградацию производительности, нет производительностного бенчмарка в приёмке). → улучшаем ПРОЦЕСС орка (домен **D2 Качество** / **D1 Надёжность**). Чинится ОДИН раз — выигрывают ВСЕ проекты. +- **Б. Project-level (недоработал ПРОЕКТ):** процесс орка нормальный, но в конкретном ET МАЛО тестов/слабая приёмка под этот тип фич. → усиливаем ТЕСТЫ/приёмку В САМОМ ET (задача в бэклог ET). Чинится точечно — выигрывает только ET. + +**Механизм (новый шаг петли):** +``` +ДЕТЕКЦИЯ деградации продукта (слой 3) → урок → + АТРИБУЦИЯ: platform-level или project-level? + ├─ platform → задача в D1/D2 (улучшить процесс — польза всем) + └─ project → задача в бэклог ET (усилить тесты ET — польза ET) + (развилка не всегда бинарна — бывает ОБА: и гейт в орк, и тесты в ET) +``` +Без атрибуции петля «чинит платформу» там, где надо усилить проект (и наоборот). **Зависит от слоя-3 детекции** (§2): без мониторинга здоровья продукта петле нечего атрибутировать. **E2-ретроспективщик** несёт эту классификацию; спорные случаи → Стрим/Слава решают. + ### 8B. Проактивная турбина 💡 — генератор идей новых возможностей (НОВОЕ — запрос Славы) > Отдельный источник идей роста функционала — НЕ только требования от Славы. Проактивно предлагает новые фичи/возможности/удобства. Та же воронка: машина/агент генерит черновики → Стрим фильтрует → Слава решает.