docs(epic): скоуп наблюдения (3 слоя) + атрибуция уроков platform-vs-project (Слава 10.06)

docs/epics/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. Проактивная турбина 💡 — генератор идей новых возможностей (НОВОЕ — запрос Славы)
 
 > Отдельный источник идей роста функционала — НЕ только требования от Славы. Проактивно предлагает новые фичи/возможности/удобства. Та же воронка: машина/агент генерит черновики → Стрим фильтрует → Слава решает.